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 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.

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.

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.

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.

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.