What a cloud migration actually costs

Almost every cloud migration estimate we have reviewed was wrong in the same direction, for the same reason: it priced the servers.

The compute and storage line is the easiest number to produce and the least likely to be the problem. Providers publish their rates, calculators exist, and the figure looks authoritative. Meanwhile the costs that overrun are the ones nobody put on the sheet.

Where the money actually goes

Egress, discovered late. Ingress is free; moving data out is not. A reporting job that pulls a full dataset to an office network, a backup written to another provider, a chatty service in a different region — these produce bills that surprise people in month three. Map your data flows before you migrate, not after.

The rates are public and worth internalising, because their shape is what catches people. AWS gives you the first 100 GB per month out to the internet free, then charges $0.09 per GB for the next 10 TB, tapering to $0.05 per GB above 150 TB. The free allowance is generous enough that development and testing never reveal the problem, and the taper is shallow enough that volume does not rescue you.

PRICE PER GB, DATA TRANSFER OUT TO INTERNET

free$0.090$0.085$0.070$0.050First100 GBNext10 TBNext40 TBNext100 TBOver150 TB

The application rewrite you did not plan. Lift-and-shift works until it meets something that assumed a fixed local disk, a static IP, a shared filesystem between processes, or a machine that never restarts. Every one of those is an application change, not an infrastructure one, and it is engineering time nobody budgeted.

Running both at once. There is a period where the old environment and the new one are both live, both paid for, and data is syncing between them. That overlap is usually longer than planned, because cutover slips. Budget for double-running, and be pleased if you beat it.

The observability you now need. On a server you could SSH into, debugging was free. In a distributed cloud environment you need logs aggregated, metrics collected and traces correlated — and those tools are priced by volume. Teams routinely spend more on observability than they expected, then economise by sampling, then lose the data they needed during an incident.

Learning, on the clock. IAM policies, VPC design, and the specific failure modes of managed services are all learned somewhere. It is either learned before the migration in deliberate spike work, or during the first production incident.

What the exit-fee change did and did not fix

Since 2024 the major providers have waived egress charges for customers leaving. Google moved first in January 2024, and AWS followed that March; Microsoft made a comparable offer for Azure. The driver is regulatory — the EU Data Act's full ban on switching charges takes effect on 12 January 2027.

This is a genuine improvement to exit economics, and it is routinely misread as "egress is free now." It is not. The waivers are narrow in ways that matter:

• They apply to switching away, not to ordinary operational transfer. The nightly reporting extract is billed exactly as before.
• They are conditional. Azure's waiver requires terminating the account and completing the move within a fixed window; AWS excludes some services from the calculation and has said it will scrutinise repeat applications.
• They are claimed after the fact, as credits, rather than simply not charged.

So the exit-cost argument against a provider is weaker than it was in 2023. The running-cost argument is unchanged, and running cost is what your architecture determines.

Two things that reliably reduce the total

Move workload by workload. A single cutover concentrates all the risk into one night and gives you nothing to learn from beforehand. Move the least critical service first, deliberately, and let it teach you what your runbook is missing while the stakes are low.

Express everything as code from the first workload. Manually clicked infrastructure cannot be rebuilt, reviewed or reasoned about, and it is where "nobody knows why this security group exists" comes from. Terraform from the start is slower on workload one and faster on every workload after — and it is what makes the environment auditable later.

Decide the strategy per workload, not per estate

AWS's seven migration strategies — the "7 Rs", extended from Gartner's original five — are a useful checklist precisely because two of them involve not migrating:

Refactoring mid-migration is the classic budget killer: it merges two projects with independent risk into one, and when it slips you cannot tell which half slipped. If a workload genuinely needs re-architecting, migrate it first and change it second — and note that "we will split it into services while we are in there" carries its own bill that has nothing to do with the migration.

What we would ask before quoting

• What actually needs to move, and what would be cheaper to retire than to migrate?
• Where does data cross a boundary today, and how much of it?
• Which applications assume local disk, a fixed address, or shared state between processes?
• What does an acceptable cutover window look like, and is a rollback rehearsed?
• Who operates this in six months, and what do they need to be able to do?

The last question changes more architectural decisions than the first four combined. A migration that lands successfully and leaves a team unable to operate the result has moved the problem rather than solved it. It is also the question our cloud and DevOps work is usually brought in to answer, long after the infrastructure diagram was agreed.

The number nobody wants to hear

For a non-trivial estate, plan for the infrastructure bill to be a minority of the total cost. Engineering time, double-running and the observability layer usually add up to more.

We are deliberately not putting a percentage on that. The split varies enormously with how much rewriting a given estate forces, and every published figure we have seen either measures a specific estate or is a vendor's own modelling. What we will say is that in the reviews we have done, the infrastructure line has never been the line that broke the budget.

That is not an argument against migrating. It is an argument for a phased plan with a rehearsed cutover, and for treating "what does this cost to run and operate afterwards" as part of the design rather than a discovery.

Questions we get asked

Will we save money by moving to the cloud? Often, but not automatically, and rarely in year one — double-running and engineering time land before any saving does. The reliable wins are elasticity for uneven load, the operational cost of managed services, and not buying hardware ahead of demand. A steady, predictable, well-utilised workload on owned hardware can be genuinely cheaper to run, and that is worth establishing before rather than after.

How long should we budget for double-running? Longer than the plan says, because cutover dates slip more often than they hold. Moving workload by workload is what limits the damage: each overlap covers one service rather than the whole estate, so a slip costs one service's duplicate bill.

Is a lift-and-shift a waste of time if we will modernise later? No — it is usually the right first step, and the 7 Rs treat it as a legitimate destination rather than a failure. It gets you out of the data centre on a known deadline with the smallest number of simultaneous changes. The trap is calling it temporary and never returning, at which point the assumptions you deferred become technical debt with a cloud bill attached.

What single thing most reduces the risk? A rehearsed rollback. Not a documented one — an executed one, on a real workload, with a stopwatch. Teams that have rolled back once cut over calmly; teams that have only written the procedure down discover its gaps at 3am.