Why cloud migrations overspend, and the three decisions that prevent it

The first decision: what you carry over

Almost every migration business case is built on a like-for-like comparison — here is what the data centre costs, here is what equivalent cloud capacity costs. The trouble is that like-for-like is the most expensive way to buy cloud, and the comparison quietly commits you to it.

On-premise capacity is bought for peak, years in advance, and the marginal cost of over-provisioning is close to zero once the hardware is on the floor. Cloud inverts that. Every idle core is billed every hour. A server sized years ago for a workload that has since halved will cost you the original size indefinitely.

Utilisation profiling on a typical estate commonly finds a substantial share of virtual machines running well below capacity. Migrating them as they stand converts a sunk cost into a recurring one.

The second decision: who owns the bill

Many organisations migrate with a single account, a single bill and no attribution. Months later the bill has grown and nobody can say which team, product or feature caused it.

This is not a reporting problem, it is an incentive problem. Engineers make cost decisions many times a day — instance class, storage tier, retention period, whether the test environment runs over the weekend. If none of those decisions has a visible consequence, the aggregate is unmanaged by construction.

The fix is structural and belongs in place before the first workload moves:

• A tagging policy enforced by policy, not by convention. Untagged resources should fail to create.
• Account or subscription boundaries that map to teams, so attribution is automatic rather than reconstructed.
• A regular cost review attended by engineers, not only by finance.

The third decision: what you keep running yourself

The comparison that matters is not instance price against server price. It is total cost of ownership, and the largest term in that expression is usually people.

Running your own database on virtual machines is cheaper per hour than the managed equivalent. It is often more expensive per year once you count patching, backup verification, failover testing, version upgrades and the out-of-hours pager. Teams routinely choose self-managed to save on a line item, then spend engineer-months on the maintenance that line item was funding.

The same applies to Kubernetes. It is an excellent answer to problems that many organisations do not yet have. Below a certain number of services, and without dedicated platform capability, a managed container service delivers the same outcome with a fraction of the operational surface.

The right question is not what is cheapest to run. It is what is cheapest to run well, given the team you actually have.

What a controlled migration looks like

The pattern that keeps migrations on budget is not complicated, and it is frequently skipped:

1. A period where nothing moves. Landing zone, guardrails, tagging, identity and cost attribution first.
2. A workload scorecard. Every application assessed individually for rehost, replatform, refactor or retire. Retiring workloads with no identifiable consumer is common.
3. Waves, with rollback rehearsed. The first wave should carry low-criticality workloads specifically to prove the runbook.
4. Cost review from the first month. The habit is harder to establish than the tooling.

Most of this is skipped because the migration date is set before the assessment is done, and everything that follows is compressed to protect that date. If you change one thing about how your programme is governed, change that.