The true cost of a cloud migration is the projected cloud run rate plus the one time transition costs of moving, which routinely add up to a large fraction of the first year: running both environments in parallel, paying egress to move data, the engineering labour to rehost or rearchitect, retraining staff, new tooling, and a temporary dip in delivery while teams learn the platform. A business case that compares only the new cloud bill to the old data centre bill omits the costs that decide whether the move actually pays.
Here is what the run rate comparison leaves out, the one time cost categories to model, how to build a business case that holds, and a worked example of where the real money goes.
Why does the run rate comparison mislead?
Most migration cases put the projected monthly cloud bill next to the current data centre cost and call the difference the saving. That comparison is incomplete in both directions. It usually understates the cloud run rate, because the first deployment is rarely optimised, commitments are not yet in place, and lift and shift workloads carry the inefficiency of their on premises sizing. And it ignores the transition entirely, the one time spend required to get from here to there, which lands in the first year and can dwarf the monthly difference. A migration that looks like a clear win on run rate can lose money for two years once the transition is counted, which is exactly when budgets and patience run out.
What one time costs should the model include?
The transition has several cost categories, and leaving any of them out flatters the business case.
| Cost category | What it covers | Why it is missed |
|---|---|---|
| Dual running | Both environments live during the move | Assumed to be brief; usually runs for months |
| Data egress | Moving data out of the source environment | Per gigabyte charges on large datasets add up fast |
| Refactoring labour | Engineering to rehost or rearchitect workloads | Estimated low; rearchitecting takes longer than rehosting |
| Retraining and hiring | Teams learning the new platform | Treated as free; it is real time and cost |
| Tooling and parallel ops | New monitoring, security, and management tools | Old tooling still runs alongside the new |
| Productivity dip | Slower delivery while teams ramp up | Invisible on a spreadsheet, real in the roadmap |
Dual running and refactoring are usually the two largest. Dual running because keeping both environments live to migrate safely means paying twice for longer than planned, and refactoring because the rearchitecting that unlocks the real cloud savings is far more labour than a straight rehost. The cheaper the migration approach, the higher the eventual run rate, and the more expensive the migration approach, the bigger the up front bill, which is the central tradeoff of the business case.
How do you build a business case that holds?
A defensible case models the full multi year picture, not a single month. Project the cloud run rate at three stages: the unoptimised first deployment, the state after rightsizing and waste removal, and the steady state with commitment coverage in place, because the savings arrive in that order over the first year. Add every one time cost category with honest ranges, label indicative figures as indicative, and show the payback period and cumulative cost, not just the eventual monthly saving. Crucially, plan the optimisation window immediately after migration as part of the case, because the gap between the lift and shift run rate and the optimised run rate is where most of the promised saving actually lives, and it does not happen on its own.
A worked example
A manufacturer built a migration case showing a healthy monthly saving against its data centre cost and got it approved. The run rate comparison held, but the first year came in well over budget because the model omitted nine months of dual running, the egress to move years of accumulated data, and the refactoring needed before the new bill matched the projection. Once the transition costs were added and an explicit optimisation window was funded to take the lift and shift workloads down to their efficient run rate, the move still paid, but the payback was nearly a year later than the original case implied. Figures are verified against billing data and anonymised; transition cost ranges are indicative.
Frequently asked questions
What costs do cloud migration business cases miss?
Why does a migration cost more than the projected cloud bill?
How do you make a migration actually pay?
Model the migration that actually pays
We build migration business cases that count every transition cost and fund the optimisation window where the savings actually live, as an independent advisory that takes zero provider commissions and answers only to you. Our guarantee: we reduce your cloud spend or we reimburse our service fee, on a Fixed Fee or a no risk Gainshare basis. Download the cloud cost optimization playbook, read the cross cloud cost optimization guide, and on the case itself see building a migration business case that holds. For monthly buyer side analysis, subscribe to The Cloud Spend Navigator.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.