Cloud Migration Cost

Part 8 gave you the sequence. This part gives you the number — or rather, the honest way to build one, because “what does a cloud migration cost?” has no single answer and anyone who offers one without seeing your estate is guessing. What this part can do is give you the structure of a trustworthy estimate: the two distinct costs that must be modeled separately, the traps that quietly inflate each, and the comparison that the whole exercise actually turns on. This is the part you bring to the CFO.

The two costs, and why they must be separated

Almost every bad cloud-cost decision starts by collapsing two different things into one. There are two costs, and they behave nothing alike:

1. The one-time cost of moving — discovery, re-architecting where you’ve chosen to, data migration, validation, and a period of running both environments in parallel. This is a project cost. It ends.
2. The ongoing run cost — the cloud infrastructure, managed services, and operations the workloads consume forever after. This is an operating cost. It compounds.

Conflating them produces two classic mistakes. Teams approve a migration on a one-time number and get blindsided by the run cost (Part 4’s surprise bill). Or they fixate on monthly cloud pricing and underfund the migration itself, then watch it overrun. Model them separately, present them separately, and the decision becomes legible.

Estimating the one-time cost

The move itself is dominated by a few line items, and their proportions tell you something about the work:

Line item	What drives it
Discovery	Estate size, how much was never documented
Re-architecting	How many workloads you’re refactoring vs rehosting (Part 3)
Data migration	Data volume, sensitivity, reconciliation rigor
Validation	Criticality — parity proof costs, and skipping it costs more
Parallel running	How long source and target run side by side

The biggest lever here is the lift-versus-refactor mix. A mostly-rehost migration is cheaper to execute and more expensive to run; a refactor-heavy one inverts that. The one-time number is meaningless without the run-cost number beside it — which is exactly why they travel together.

Estimating the ongoing run cost

This is the harder of the two, for a structural reason: the run cost depends on the target architecture, which doesn’t exist yet when the estimate is made. Teams default to estimating it from the source system’s current resource usage. That estimate is reliably wrong, because a workload lifted unchanged runs differently on metered infrastructure than a re-architected one — usually more expensively, since it can’t scale down when idle and doesn’t use the cheaper managed services.

This gap has a name and a measurement: Flexera’s surveys consistently find organizations self-estimate that roughly 30% of cloud spend is wasted (Flexera, State of the Cloud), and the same research reports that the large majority of organizations name managing cloud spend as their top cloud challenge (Flexera, State of the Cloud, 2024). That 30% is the distance between the bill people expected and the one they got — and almost all of it is decided at architecture time, not in the monthly tuning afterward. Model the run cost of the target, design cost in as a constraint, and most of that waste never accrues.

The trap nobody puts in the spreadsheet: the cost of risk

Here is the line item that separates an honest estimate from a seductive one. Every migration approach carries a risk cost — the expected cost of the ways it can go wrong, weighted by how likely they are. A big-bang migration’s headline quote ignores this entirely, which is exactly why it looks cheap: it prices the happy path and omits the overrun, the failed cutover, the production incident, the quarter of frozen roadmap. Given the ~70% transformation failure rate (BCG, 2023), pricing only the happy path is pricing the unlikely case.

An incremental, parity-first approach costs more to set up — the facade, the parity gates, the parallel running are real expenses — and dramatically less when something surprises you, because a surprise is a failed gate caught before production rather than an outage discovered after it. You are not just buying a migration. You are buying down a failure rate, and a method that does that is worth the setup cost it adds. The cheapest quote is rarely the cheapest outcome.

The comparison the whole thing turns on

A cloud migration cost is only ever meaningful against an alternative, and the alternative is almost never zero. Leaving the system where it is has its own cost: the maintenance burden — Deloitte’s CIO surveys put run-the-business spend at roughly 55–57% of the enterprise IT budget — plus the rising risk of unsupported runtimes, the scarce skills, the features the business can’t ship. Standing still is a number too, and it usually grows.

The decision is not “migration cost versus zero.” It is “the cost of moving, plus the cost of running afterward, versus the cost of staying, plus the risk of staying.” Built that way, with the target modeled honestly and the alternative priced, the estimate stops being a scary number and becomes a comparison a CFO can actually reason about. To put real figures against your current system’s side of that comparison, the legacy cost calculator is a place to start.

Run cost is a discipline, not a one-time estimate

One more thing the spreadsheet hides: the ongoing run cost is not a number you set once at migration and forget. Cloud spend drifts upward on its own — workloads get over-provisioned “to be safe,” idle resources linger, and the convenience of spinning things up isn’t matched by discipline about spinning them down. The same Flexera research that puts wasted spend near 30% finds that the large majority of organizations name managing that spend as their top cloud challenge, year after year — which tells you it’s an operating practice, not a setup task.

The practical implication for the estimate is that the run-cost figure has to assume active cost management, not a set-and-forget bill. That means the architecture is designed to scale down as well as up, spend is tagged and attributable from day one (Part 8’s landing zone), and someone owns watching it. A run-cost estimate that assumes nobody will optimize after go-live is estimating the wasteful path on purpose. The well-architected, actively-managed number is achievable — but only if you budget for the discipline that produces it, rather than treating the first month’s bill as destiny.

Why no number is real before discovery

No estimate built before discovery is reliable, and any firm — including a good one — that hands you a precise multi-year figure from a brief description is selling certainty it doesn’t have. The honest commercial shape acknowledges this: a bounded, fixed-scope discovery phase first, which produces a grounded estimate from your actual code and data, before the large commitment. That isn’t a hedge; it’s the only point at which the numbers in this article become real rather than illustrative. Treat any pre-discovery figure as a hypothesis to be tested, not a budget to be banked.

Where this leads

You now know what a migration costs and how to reason about it. The last decision — the one that shapes cost, risk, and outcome more than any spreadsheet — is who does the work. Part 10, Cloud Migration Services and Partners, closes the series with the criteria that separate a partner who buys down your risk from one who simply moves your boxes and bills you for it.