A cloud migration that comes in on time and over budget is not unusual. It is close to the default outcome when the programme was scoped as a migration rather than as a change in how infrastructure is operated.
The mechanics are straightforward. Workloads are sized against their on-premises specification, which was itself sized for peak load plus headroom, plus a margin because adding capacity to a physical box takes weeks. That sizing gets carried into an environment where capacity can be added in seconds — and nobody revisits it.
What actually drives the number
Three things, usually in this order.
Nothing was resized. A virtual machine provisioned for the busiest hour of the busiest day runs at that specification for every other hour too. On-premises that was a sunk cost. In cloud it is a meter.
Nothing turns off. Development and test environments that were simply always on now bill continuously. This is often the single largest avoidable line, and the easiest to fix.
Storage accumulates quietly. Snapshots, backups and orphaned disks from decommissioned machines survive the workloads that created them. No one notices because no one owns the total.
The structural problem underneath
Each of those has a fix, and the fixes are well documented. The reason they do not get applied is that the operating model did not change.
On-premises, capacity was a procurement decision — infrequent, deliberate, and reviewed by someone accountable for the budget. In cloud, capacity is a deployment decision, made continuously by engineers who are measured on delivery rather than on spend, and who have no visibility of the cost of what they just provisioned.
That is not an engineering failure. It is a governance gap that migration created and nobody closed.
What closing it involves
Cost governance has to be designed in, not retrofitted. In practice:
- Tagging enforced at deployment. Untagged resources cannot be attributed, and unattributed cost cannot be reduced. This has to be a policy that blocks, not a convention.
- Environments with a lifecycle. Non-production should have a schedule and an expiry date by default.
- Right-sizing as a routine. A recurring review against actual utilisation, not a one-off exercise after the first alarming invoice.
- Cost visible to the people creating it. Engineers make sensible decisions when they can see the consequence. Most cannot.
Migrating well in the first place
The cheaper path is to treat the target architecture as the deliverable, and the migration as the means. That means designing the landing zone, the identity model, the network topology and the cost controls before the first workload moves, then migrating in waves with defined exit criteria.
It is slower to start and materially cheaper to run. The alternative — move everything, then optimise — means paying for the unoptimised estate for however long the second programme takes to fund and staff.
VYLQORA designs and delivers cloud migrations with cost governance built into the landing zone. Talk to us about what your estate would actually cost.
Written by VYLQORA. Have a view, or a problem this touches? Start a conversation.