The reason is that on-prem economics don't translate cleanly to cloud economics. On-prem, you pay for the box whether it runs at 5% or 95% utilization. In the cloud, every running minute, every GB transferred, every API call, and every idle resource has a meter. The infrastructure you architected for fixed-cost economics behaves like a luxury car on a per-mile rental plan when you put it in the cloud unchanged.
This is the trap. Lift-and-shift looks cheap because the migration project is simple — same architecture, just different hardware. The bill that arrives three months later tells a different story.
Why bills balloon after a lift-and-shift
Three forces conspire to multiply the bill in the first 12 months after a naive migration:
1. Oversizing carries over
Workloads that ran on physical servers were typically provisioned for peak plus a generous safety margin — often 3–5x the real average load. In the cloud, that means you're paying for capacity that's idle most of the time. The fix is rightsizing, but rightsizing requires telemetry that wasn't usually instrumented on-prem.
2. No unit economics
On-prem, "what does it cost to process one customer order?" is a question nobody could answer, so nobody asked. In the cloud, you can answer it — but only if you've tagged resources by business unit, application, and environment from the moment they're created. Most teams discover this six months in and spend three months retroactively tagging while the bill keeps growing.
3. Commitments left on the table
Reserved instances, savings plans, and committed-use discounts can knock 30–60% off the price of compute and storage you know you'll consume. They require commitment — actual usage forecasts — which require operational maturity that's usually behind the migration.
The 7Rs, but with money attached
The "7 Rs" of cloud migration (rehost, replatform, refactor, repurchase, retire, retain, relocate) is a familiar framework. What's less familiar is attaching unit economics to each decision before you make it.
- Rehost — Cheap to migrate, expensive to run. Best for workloads with short remaining lifespan or where exit is the next step.
- Replatform — Modest re-architecture (managed database, container runtime) that often pays back within 12 months. The sweet spot for most workloads.
- Refactor — Significant rework. Justified when the workload is strategic, will run for 5+ years, and current architecture creates ongoing operational drag.
- Repurchase — Replace with SaaS. The most painful change-management decision but often the cheapest 5-year answer.
- Retire / Retain — The most underused options. A lot of workloads don't need to move at all.
The decision per workload should be based on three numbers: 5-year total cost of ownership, time to value, and operational risk during transition. If you can't fill those three numbers in for a workload before you start migrating it, you're not ready to migrate it.
FinOps from day one, not month nine
The single most leveraged thing you can do early in a migration is treat cost as a first-class architectural concern from the first workload. Specifically:
- Tagging policy enforced at provisioning time. Untagged resources get rejected or auto-tagged with an owner. This sounds bureaucratic; in practice it's the difference between knowing your unit economics and not.
- Cost allocation dashboards by business unit and application. Built in week one, not month nine. Visible to the engineering teams whose decisions drive the cost.
- Budget alerts at multiple thresholds. 50%, 75%, 100% of expected monthly spend per workload. The alert goes to the team that runs the workload — not to finance.
- Commitment strategy with a quarterly review. A rolling forecast that converts steady-state usage into reserved instances and savings plans. Don't wait until the bill is mature to commit; commit and adjust.
FinOps isn't a department. It's a discipline. When it shows up after the bill has already exploded, the conversation is about damage control. When it shows up before the first workload moves, the conversation is about engineering trade-offs — which is the conversation you actually want to be having.
The pattern that works
The migrations that pay for themselves within 12 months share a few things in common:
- The landing zone — networking, identity, governance, tagging — was designed before the first workload moved.
- Each workload had a target architecture (rehost / replatform / refactor) decided up front, with TCO attached.
- Cost telemetry was visible to engineering teams in week one, not when the CFO asked.
- The first commitment purchases happened within 3 months of steady-state usage stabilizing.
- An exit criteria existed: "the migration is done when these workloads are running here at this cost with this reliability."
The migrations that don't pay for themselves look the same on day one and very different by month nine. By the time the cost surprise hits, the team has moved on to the next wave, the executive sponsor is reading a different status deck, and the bill becomes someone else's problem.
The good news: this is one of the cheapest problems to avoid. A two-week assessment up front, a clear landing-zone design, and a FinOps practice on day one will save more than they cost — usually within the first quarter after the first workload goes live.