Cloud Migration Cost: What Good Looks Like

Cloud migration cost is the sum of every outlay a migration effort makes to relocate workloads, data and their supporting controls into cloud infrastructure, plus the recurring bill that remains once the relocation is finished and the temporary migration apparatus is switched off. Cloud migration cost spans more than a pricing calculator's output, because the costs that decide the outcome are rarely the ones the calculator sees. A model limited to instance hours and storage tiers includes the target environment only, and the target environment is seldom where the budget breaks.

This page explains the costs of cloud migration and identifies who requires this information.

This page answers one question: what does a credible cloud migration cost model contain, and what figures should appear on it. It explains the two cost stacks that must be kept apart, the benchmark bands that let you check a quote, the metered prices that appear in provider documentation, the drivers that cause drift, and the controls that keep the forecast. It does not cover workload assessment, placement decisions, supplier evaluation or cutover execution. Those are separate bodies of work with their own depth, and this page is the map rather than the territory.

The reader who needs this page is the individual who owns the number: the migration lead defending a budget, the finance or FinOps partner holding the model against actuals, and the architect who has to justify a migration approach in cost terms rather than preference.

Project cost and run cost are separate models

Every migration contains two costs that behave differently. Project cost is temporary and volatile: it exists only to move workloads, it disappears at cutover, and it spikes when planning is weak. Run cost is the steady-state cloud bill that remains afterwards, and it decides whether the migration yields savings. Mixing the two creates a model that cannot be defended, because a one-time spike and a recurring charge do not respond to the same controls. The table below shows the distinction.

Cost stack	What it contains	When it ends	What makes it drift
Project cost	Labour, tooling, data movement, temporary environments, partner time, training, double-run overlap	At cutover, once temporary resources are decommissioned	Weak ownership, untracked dependencies, unplanned refactoring, delayed cutover
Run cost	Compute, storage, networking, managed services, observability, security tooling, platform team effort	Continues indefinitely	Overprovisioned sizing, idle resources, poor tagging, missing rightsizing

For a method that ties project and run cost into one forecast, see this cost planning for cloud migration resource.

Benchmark bands by estate size

Benchmark figures exist to check a quote, not to replace one. The UK pricing guide from Suffescom places small business migrations at £5,000 to £15,000 over one to two months, mid-sized migrations at £15,000 to £50,000 over two to six months, and large enterprise migrations at £50,000 to £200,000+ over six to ten months. Those bands assume a defined scope; they widen quickly when dependency mapping is incomplete.

Business size	Estimated project cost	Estimated timeline
Small business	£5,000 to £15,000	1 to 2 months
Mid-sized business	£15,000 to £50,000	2 to 6 months
Large enterprise	£50,000 to £200,000+	6 to 10 months

Source: Suffescom's UK cloud migration pricing guide.

For a global view, Cloudaware's enterprise cost guide reports that small workloads under 100 servers typically cost $20,000 to $100,000; mid-market migrations of 100 to 500 servers cost $100,000 to $500,000+; and enterprise migrations of 500+ servers cost $500,000 to several million dollars. The same guide reports that the biggest cost drivers are labour, data movement, integration work and the double-run period, not compute and storage. Cloudaware also reports that many enterprises target 20% to 40% infrastructure cost reductions, with results depending on workload fit and post-cutover controls.

Metered service prices you will meet in a quote

Provider pricing pages give exact figures for specific migration services. Google Cloud's Database Migration Service charges no additional fee for homogeneous migrations to Cloud SQL or AlloyDB for PostgreSQL. For heterogeneous migrations, change data capture is tiered and backfill is a flat rate with a monthly free allowance. The table below reproduces the key values from the Google Cloud Database Migration Service pricing page.

Migration method	Volume tier	Price	Comment
CDC	0 to 2,500 GiB	$2.00 per GiB per month per account	Tiered; higher volumes reduce the unit price
CDC	2,500 to 5,000 GiB	$1.50 per GiB per month per account	Reduced price applies only within the tier
CDC	5,000 to 10,000 GiB	$1.20 per GiB per month per account
CDC	10,000 GiB and above	$0.80 per GiB per month per account	Contact sales beyond 10 TiB
Backfill	0 to 500 GiB	Free	Monthly allowance per account
Backfill	500 GiB and above	$0.40 per GiB per month per account	Flat rate

Source: Google Cloud Database Migration Service pricing.

The same Google Cloud pricing page gives a worked example: a job with 600 GiB of backfill and 3,000 GiB of monthly change data capture in Iowa costs $40.00 for backfill and $5,750.00 for CDC, a total of $5,790.00, before the cost of the target Cloud SQL resource. That example shows what a provider-side migration service line item looks like when it is modelled properly, and it shows how quickly a figure that looks like a per-gigabyte charge becomes a five-figure line.

Where the money actually goes

Four drivers decide most of the total, and none of them is the instance price. Labour is the first. Cloudaware's cost guide identifies labour, data movement, integration work and the double-run period as the largest cost drivers, not compute and storage. Data movement is the next. Cloudaware reports that transfer charges, egress and short-lived storage often become the biggest early spikes, especially when on-premises dependencies draw out the process. Migrations rarely happen in one pass, so teams run multiple syncs, create temporary snapshots, check loads and repeat cycles during testing.

Licensing is the third. DXC's cloud migration cost guide reports that software licensing costs can be 300% more than the total cost of running cloud workloads, citing AWS. The same guide reports that licences form a substantial part of total cost of ownership and a strong driver of savings when they are managed deliberately.

Double-run is the fourth. Cloudaware's guide identifies the double-run period as the most common source of budget overruns, because testing takes longer than planned, approvals slip, and legacy and cloud environments end up running in parallel. Without firm cutover criteria and assigned owners, that overlap becomes a recurring cost with no defined closing point.

The overrun statistics that should shape the contingency

CACI's 2026 cloud migration challenges guide reports that organisations spend on average 14% more on migration than planned, that 38% of migrations are delayed by more than three months, and that 84% of organisations struggle to manage cloud spend effectively. Those figures matter because they describe the failure modes a contingency has to cover: optimistic planning, delayed cutover and weak post-cutover governance. A contingency set as a flat proportion of project cost will not cover a delayed cutover, because the largest cost in that scenario is the double-run overlap, which grows with time.

The same guide groups migration challenges by phase, from strategy and business alignment through discovery, architecture, security, data and integration, cost governance, and people. Each phase changes the cost model. Discovery decides whether the baseline is complete. Assessment decides whether a workload is rehosted, replatformed or retired. Mobilisation decides whether the landing zone, identity, networking and policy controls are ready before workloads arrive. Migration decides how long old and new environments run in parallel. Optimisation decides whether the cloud bill reflects production behaviour or migration-phase sizing. Governance decides whether the post-cutover environment stays clean.

A credible model contains information about what a migration budget includes.

A credible cloud migration cost model keeps the project stack and the run stack on separate lines, with a manager for each line. It records the assumptions that drive each figure, including workload count, dependency depth, data volume, overlap duration, licensing position and compliance scope. It includes a contingency tied to the overrun risks above rather than a flat proportion. It establishes a cutover criterion that includes a maximum overlap period and a designated manager to end the move. It reconciles the forecast against actuals at each phase boundary, not only at the end.

The model should also show the figures that will not move: provider list prices for the services in scope, the transfer charges that apply to each data path, the licence position for each application, and the labour estimate for each workstream. Those are the values a finance partner can challenge without restarting the model from zero. The pages beneath this one cover workload assessment, placement, supplier evaluation and cutover execution in depth. This page is the map.