Planning a cloud migration that does not end up costing more

A cloud migration that increases running cost is common enough to be the default outcome when planning is skipped. The causes are consistent.

Cause one: migrating the specification rather than the workload

On-premises servers are sized for peak load plus a hardware refresh cycle's worth of headroom, because adding capacity later means buying a machine. That sizing logic makes sense when compute is capital. It is actively wasteful when compute is metered by the hour.

A server specified at sixteen cores and 128 GB because that was the sensible purchase in 2021 may be using two cores and 24 GB. Migrating it as-is means paying continuously for the fourteen cores it never uses.

The fix: measure actual consumption over a representative period before sizing anything. Not peak, not the specification — measured utilisation.

Cause two: everything running continuously

On-premises, a development environment left running costs nothing incremental. In a public cloud it bills every hour. Non-production environments frequently account for a surprising share of a migrated estate's bill, and they are typically needed during working hours only.

The fix: schedule non-production environments off outside working hours. It is a small piece of automation with a large and permanent effect.

Cause three: no commitment on the stable baseline

Cloud providers discount substantially for committed capacity. Organisations often avoid commitment because they are uncertain about their consumption — which is reasonable in month one and unreasonable in month twelve.

The fix: run on-demand until the baseline is measured rather than estimated, then commit the genuinely steady portion and leave the variable portion on-demand.

Cause four: storage that was never reviewed

Migrated storage arrives at the performance tier the source system used, and stays there. Data that is written once and read rarely does not need premium storage, and the price difference across tiers is large.

The fix: classify data by access pattern and place it accordingly. Lifecycle policies can automate the transition.

Cause five: nobody owns the bill

Without cost allocation, no individual team sees the consequence of leaving something running. Spend becomes a general overhead that nobody is accountable for.

The fix: enforce tagging from day one and report cost by team or product. Visibility alone changes behaviour, before any policy is applied.

The planning sequence that avoids this

Measure current consumption. Model the cost with the measured figures. Build the governance layer before workloads move. Migrate. Right-size against observed load. Commit once the baseline is real.

That sequence takes longer to start and considerably less to recover from.