The short version
- The gap between case and invoice is six ordinary things, not one big one.
- Sizing to specifications rather than measured behaviour is the largest single cause.
- Egress and non-production run-time are the two lines most often missing entirely.
- Nobody owning the bill is the structural problem underneath the other five.
The business case was built on list prices and a spreadsheet. The invoice is built on what your workloads actually do at 3am. The gap between those two things is where cloud migrations lose their credibility — and it is almost entirely predictable.
We are frequently brought in after a migration, not before, and asked why the run rate is higher than the case said it would be. The answer is rarely one big thing. It is six or seven ordinary things that each look small in isolation.
1. You sized for peak, and then paid for peak all month
On-premise, you buy for peak because you have to. That instinct carries into the migration, and the lift-and-shift maps a physical server that ran at 12% average utilisation onto an instance priced for its specification, not its behaviour.
The fix is not clever, it is just work: measure actual CPU, memory and IO over a representative period — including month-end, quarter-end and whatever your seasonal peak is — and size to that with headroom, rather than to the tin you happen to own.
The number worth having before you move anything
For every workload: 95th-percentile CPU and memory over ninety days, peak IOPS, egress volume, and whether it can tolerate being stopped. Those five figures determine most of your bill, and almost nobody collects them before signing the business case.
2. Storage tiering never happened
Data that was on a cheap array on-premise arrives on premium block storage in the cloud, because that was the default in the migration tool. Snapshots accumulate on a schedule nobody revisits. Backups of dev environments are retained for seven years because the policy was written once, for production, and applied everywhere.
Storage is quiet. It does not page anyone. It simply grows, and a year later it is a material line on the invoice.
3. Egress
Data movement out of the cloud is the cost line most consistently missing from business cases, and it is the one that scales with exactly the integration patterns a modernisation programme encourages. Chatty applications split across on-premise and cloud, analytics pulling full extracts nightly, backup targets in a different provider — each is a defensible design decision and each has a per-gigabyte price attached.
4. Non-production runs like production
Development, test, staging and training environments frequently run 168 hours a week to serve a team that works 40. Turning them off outside working hours is the single highest-return action available in most estates, and it typically requires nothing more than a schedule and someone with the authority to say yes.
5. Licensing moved in an unfavourable direction
Database and operating system licensing under a cloud vendor's terms can differ substantially from an existing enterprise agreement, and the difference is per-core. This is knowable in advance and frequently is not checked, because it sits between the infrastructure team and procurement and belongs to neither.
6. Nobody owns the bill
The structural problem underneath the other five. When cloud spend lands as one invoice against one cost centre, no individual team sees the consequence of its own decisions, and no individual team can be asked to improve them.
Tagging workloads to owners, and producing a monthly report that shows each owner their own spend and its trend, changes behaviour more reliably than any optimisation tool. It is also the prerequisite for every optimisation tool being useful.
Cost control is not a phase after migration. It is a design input before it, or it is a recurring argument afterwards.
What a defensible business case contains
- Modelled run-cost per workload, from measured behaviour rather than specifications — with the measurement period stated.
- Egress modelled from the target architecture, not omitted.
- A non-production policy with schedules, agreed before migration rather than after the first invoice.
- Licensing position confirmed in writing with procurement in the room.
- Ownership and tagging standard defined, and enforced at provisioning.
- A stated variance band. A case that claims precision it cannot have is less credible than one that says plus or minus fifteen per cent and explains why.
And if you have already migrated
Then you have something better than a model: an actual bill, with actual usage behind it. A cost review against a live estate typically identifies enough in over-provisioning, orphaned storage and always-on non-production to pay for itself within a quarter. It is the least glamorous engagement we run and one of the most reliably valuable.
