The cloud migration cost trap — and how to avoid it

The most common cloud disappointment is not a technical failure. It is a finance conversation in month four, when the bill is higher than the data centre it replaced and nobody can explain which team is responsible for which portion of it.

This happens because lift-and-shift preserves every sizing decision made under a different cost model. A server provisioned for peak load five years ago and never revisited becomes an always-on instance billed by the hour.

The remedy is a right-sizing and tagging pass before the migration, not after. Measure actual utilisation, tag every resource to a cost centre at creation time via policy, and build the showback report on day one so spend has an owner from the beginning.

Then pick the modernisation targets deliberately. Not everything should become serverless. The workloads worth re-architecting are the ones with spiky demand or high idle time; steady-state workloads are often cheapest on reserved capacity, and that is a perfectly respectable answer.