GEICO spent a decade moving workloads to the public cloud on the promise that costs and complexity would fall. The insurer's platform engineering leader has since said publicly that the bills came in at roughly 2.5 times the anticipated number, and reliability suffered along the way. The company started pulling storage-heavy workloads back on-premises.
That story is unusual only in its scale. The same pattern shows up on a smaller stage every month: a team lifts servers into the cloud without rethinking the architecture, and the first full invoice after cutover doesn't match the business case anyone signed off on. A short walkthrough of the six cloud migration mistakes worth avoiding covers the planning and data-location questions that tend to get skipped in the rush to a cutover date.
Two Migrations Sit Behind Every Cloud Move
There's the migration where you move the machines, and there's the migration where you redesign the workload for the platform you're moving it to. AWS frames these as separate strategies inside the 7 Rs framework — rehost, replatform, relocate, refactor, repurchase, retire, retain. Lift-and-shift is rehost. It's the fastest of the seven, and for good reasons it's often the right first move: fewer code changes, a compressed timeline, and a clean cutover date the business can plan around.
Rehosting relocates the workload and buys time to do the harder work later, but the project isn't finished on cutover night. The trouble starts when a team treats that night as the end of the project and closes the ticket.
The Old Bill Was Predictable; the New One Isn't
An on-prem estate bills you for what you own. A cloud estate bills you for what you use, at rates that vary by service, region, and time of day. Those are two different accounting problems, and a lifted workload keeps behaving like the first one while being priced like the second.
Three line items tend to surprise people on the first full invoice:
- Idle compute. Instances sized for peak on-prem load run at low usage 20 hours a day, and you pay full rate for every one of those hours.
- Data egress. Moving data out of the cloud, between availability zones, or through a NAT Gateway carries per-GB fees that add up quickly. DigitalOcean's egress breakdown walks through AWS's tiered rates and the cross-zone charges most teams forget to model.
- Managed service premiums. Rehosted databases and message queues often land on managed equivalents priced well above the raw compute underneath them.
None of these are hidden. They're all published. They just weren't in the spreadsheet that justified the move.
Identity and Access Get Sorted Later, Which Means Never
The other thing lift-and-shift tends to defer is identity. On-prem, permissions accreted over years inside a domain controller and a handful of app-level roles. Rehosting drops that whole tangle into a cloud account where every service, every key, and every role is a first-class object with its own blast radius.
Teams that don't redesign identity during the migration end up with over-broad service accounts, long-lived access keys nobody rotates, and a break-glass role three engineers quietly share. It works until an audit or an incident forces the cleanup, and then it works badly.
A Plan Covers What a Runbook Can't
A cutover runbook tells you how to move the workload on the night you move it. A migration plan tells you why you're moving each workload, what shape it should take on the other side, and how you'll know afterward whether the move worked. They're different documents, and only one of them survives contact with the first invoice.
A real plan, written before anything moves, covers at minimum:
- A per-workload strategy. Which of the 7 Rs applies to each application, and what the acceptance criteria are for calling that workload migrated.
- A landing-zone design. Accounts, networks, identity boundaries, and logging set up before the first workload arrives, not retrofitted around it.
- A cost model with owners. Forecast spend by workload, tag everything on the way in, and assign a name to the person who has to explain variance.
- A post-cutover backlog. The list of replatforming and refactoring work that has to happen in the six months after the move to bring the bill in line with the business case.
When Lift-and-Shift Still Wins
None of this is an argument against rehosting. When a data center lease is ending, when a hardware refresh would cost more than a year of cloud spend, or when a workload is genuinely a candidate for retirement inside 18 months, lift-and-shift is the honest answer. The mistake isn't choosing it. The mistake is choosing it by default, on every workload, and then acting surprised when the invoice reflects that choice.
The teams that come out of a migration with a defensible bill are the ones who treated the cutover as the midpoint of the project, not the finish line. They budgeted for the second migration, the redesign, before the first one started.
