Ask a room of CIOs about failed cloud migrations and you will hear stories about incompatible workloads, surprise costs, and vendors who disappeared after cutover. Look closer at those stories and a pattern emerges: the failure was set up months before the first server moved. The migration had a project plan, a budget, and a go-live date — but nobody owned what happened on day two.
The go-live illusion
Treating go-live as the finish line is the founding error of most migration programmes. A migration that ends at cutover simply relocates your problems to someone else's data centre — often at a higher monthly cost. The value of cloud is unlocked in the months after the move: rightsizing what you over-provisioned, re-architecting what you lifted, and building the cost and reliability discipline the new platform demands.
That work needs an owner with a mandate and a budget, named before the migration starts. When post-migration optimisation is left as an implicit follow-up, it competes with every new roadmap item — and loses.
Three questions that predict success
Before any workload moves, three questions deserve written answers. Who owns the cloud bill, per product, after cutover? Which workloads are being re-architected rather than rehosted, and why those? And what does rollback look like for each cutover if the rehearsal fails? Teams that can answer these tend to land migrations early and under budget. Teams that cannot are usually renegotiating their cloud contract within a year.
Plan the second quarter first
The practical fix is to plan the first ninety days after migration with the same rigour as the migration itself: a costed optimisation backlog, capacity baselines captured before the move, and monthly targets for spend and performance. When the after is planned first, the move itself becomes what it should be — a controlled, rehearsed, slightly boring event.
