Cloud migration cost and planning: what the business case leaves out

A cloud migration costs whatever the destination costs to run, plus the price of getting there, plus the price of running two estates at once while you do. Most business cases model the first number carefully and the other two loosely, which is why overruns are the norm. Budget the migration in waves, cap the dual-running period, and decide each application's treatment before you estimate it, not after.

The pattern is well documented. McKinsey's survey of around 450 CIOs and technology leaders found that migration inefficiencies cost the average company 14 percent more than planned each year, that 38 percent had seen migrations delayed by more than a quarter, and that outside change management, spending on systems integrators was the most cited source of overrun. Once the estate is live, Flexera's State of the Cloud research has put estimated wasted spend on infrastructure and platform services at 27 percent in its 2025 report and 29 percent in 2026, with 84 percent of organisations naming cloud cost management as their top cloud challenge.

The five cost buckets

A credible migration budget separates five kinds of cost, because they behave differently and are owned by different people.

• Assessment and planning: discovery of the estate, dependency mapping, application-by-application treatment decisions and landing-zone design. Usually a small share of the total, and the share most often cut.
• Migration labour: rehosting, replatforming or refactoring each application, plus data migration, testing and cutover. This is the bucket that overruns, because refactoring effort is estimated before anyone has read the code.
• Dual running: the period when you pay for the old environment and the new one simultaneously. Data centre leases, licences, support contracts and staff do not stop on the day the first workload moves.
• Run rate: compute, storage, network egress, managed services, licences moved to cloud terms, monitoring, security tooling and support plans in the new environment.
• Organisational change: training, new operating roles such as cloud platform and FinOps, revised processes for provisioning and change, and the productivity dip while teams learn.

The dual-running trap

The single most controllable variable in a migration budget is how long you pay twice. Programmes that migrate application by application without a plan for exiting each data centre, rack or contract end up with a long tail of small workloads keeping expensive infrastructure alive. A useful planning discipline is to group applications into waves defined by what they let you switch off: a wave is complete when a contract, a cluster or a facility can be decommissioned, not when the applications are running in the cloud.

Tie the plan to exit dates you already have. Hardware refresh cycles, data centre lease expiries and licence renewals are natural deadlines, and they turn decommissioning from an aspiration into a saving with a date.

Decide the treatment before you estimate

Every application needs one of a small set of treatments before its cost can be estimated with any honesty: retire it, retain it where it is, rehost it as-is, replatform it onto managed services with modest changes, refactor it substantially, or replace it with SaaS. The common mistake is to estimate the whole estate as if it were a rehost and discover refactoring needs in flight.

• Retire anything with negligible usage. Most estates contain applications nobody would notice switching off, and every one retired is a migration you do not pay for.
• Rehost when speed matters and the application is stable, then optimise in the cloud. Lift and shift is a reasonable first move and a poor destination.
• Replatform databases and middleware onto managed services where the operational saving is clear and the code change is small.
• Refactor only where the business case depends on it: scale, release speed, or retiring a legacy platform that is itself the cost problem.
• Replace with SaaS where the capability is not differentiating and a mature product exists.

Build the business case on unit economics

A total cost of ownership comparison between the current data centre and a projected cloud bill is necessary but rarely persuasive, because both numbers are uncertain. A stronger case measures cost per unit of business activity, such as per transaction, per customer or per claim processed, before and after migration. It also captures the benefits that do not show up on an infrastructure invoice: faster environment provisioning, shorter release cycles, and the avoided cost of the next hardware refresh.

Be explicit about which savings are structural and which depend on behaviour. Right-sizing, reserved capacity and turning off non-production environments overnight are real savings, but only if someone owns them after the migration team has moved on.

A planning sequence that holds up

• Weeks 1 to 6: discover the estate, map dependencies, agree treatment per application, and design the landing zone with identity, networking, security and cost tagging in place from day one.
• Weeks 4 to 10: migrate a pilot wave of low-risk applications end to end, including cutover and decommissioning, and use the actuals to recalibrate every remaining estimate.
• Following quarters: run migration waves sized to decommissioning milestones, with a fixed cadence of cost reviews and a FinOps owner accountable for run-rate from the first wave.
• Throughout: keep a visible register of dual-running costs and the date each will stop, reported alongside migration progress.

Questions to settle before you sign anything

• Which contracts, leases or refresh dates create our natural exit deadlines?
• Who owns the run-rate budget once workloads land, and how will they see it by team and application?
• What are our data egress and replication costs during and after migration, and have we modelled them per wave?
• Which licences move to cloud terms favourably, and which become more expensive?
• Have we checked the funding and credits available through the cloud providers' migration programmes?
• What is our rollback plan for each wave, and how long will we keep the old environment warm?

How Webneuron helps

Webneuron plans and executes cloud migrations on AWS, Azure and Google Cloud, from discovery and landing-zone design through wave execution and post-migration optimisation. We build the plan around what each wave lets you switch off, put cost tagging and FinOps ownership in place before the first workload moves, and stay on to run or hand over the platform. On a discovery call we can review your estate and tell you where the business case is strongest and where it is thin.

Frequently asked questions

How much does a cloud migration cost? It depends on estate size and treatment mix, but the total is the sum of assessment, migration labour, dual running, the new run rate and organisational change. Dual running and refactoring effort are the two items most often underestimated.

Why do cloud migrations go over budget? Usually because applications are estimated before their treatment is decided, dual running lasts longer than planned, and run-rate costs have no owner once workloads land. McKinsey found average overspend of 14 percent a year on migration.

How long does a cloud migration take? A pilot wave can complete within one to three months. A mid-sized enterprise estate typically migrates over 12 to 24 months in waves, paced by decommissioning milestones.

Is it cheaper to run in the cloud than on premises? Not automatically. Cloud is cheaper when capacity matches demand, idle resources are switched off and managed services replace operational labour. Without that discipline, a straight lift and shift can cost more.

Sources

• McKinsey & Company, Cloud-migration opportunity: Business value grows, but missteps abound (survey of around 450 CIOs).
• Flexera, 2025 State of the Cloud Report and 2026 State of the Cloud findings.
• Webneuron case study: modernising a core banking platform without a big-bang cutover.