Every cloud migration business case has the same shape. Hosting costs go down, agility goes up, and somewhere around month twelve the data centre contract ends. Then the programme runs, the workloads move, the team celebrates go-live, and eighteen months later the finance team asks why the company is still paying for racks.
I have seen this on enough programmes to treat it as the default outcome rather than the exception. The migration gets declared finished when the new environment is switched on. The saving only exists when the old one is switched off, and those are different milestones separated by a long tail of work nobody scoped.
The workloads that move first are the ones with owners. Someone runs them, wants them modernised, and turns up to migration planning meetings. What is left at the end is everything else: the reporting server one team in one state still uses quarterly, the file share with a decade of contracts on it, the integration job that runs monthly and fails silently, the application whose vendor no longer exists.
None of these block the migration, so they get deferred. But every one of them keeps the data centre bill alive, and each has a small constituency with a reason to leave it alone. Six months after go-live, the remaining 10 per cent of workloads carry 100 per cent of the old fixed costs, and there is no programme left to deal with them.
We plan decommissioning from the first week, and it changes how the whole migration runs.
Every workload in the estate gets a disposition before anything moves: rehost, replatform, refactor or retire. Retire is a first-class outcome, not a fallback, and on most estates it is the right answer for more workloads than anyone expects. A system that nobody can name an owner for is a retirement candidate until someone claims it.
The migration waves are then ordered so that infrastructure can actually be released behind them. Moving workloads in an order that empties a rack, a host cluster or a network segment lets you shrink the physical estate progressively, rather than running everything until the very last workload moves.
The data centre exit date goes in the plan as a milestone with a name against it, the same as go-live. When the exit date is a real commitment, the awkward tail workloads get decisions instead of deferrals, because someone has to answer for the date.
The most common blocker at the end is data nobody wants to move and nobody is willing to delete. The answer is rarely to migrate it as-is. Cold storage tiers exist for exactly this: contracts, logs and historical records move to archive storage at a fraction of the cost of running the server they lived on, with retention policies that finally get documented in the process. The server retires; the obligation is met.
On a recent programme we ran the disposition exercise across roughly two hundred workloads. About a quarter retired outright, which surprised the client and shortened the migration by months. The waves were sequenced to release hardware progressively, and the hosting contract was renegotiated twice on the way down instead of once at the end. The final state was the one the business case had promised, on a date someone had committed to in writing.
That is the standard worth holding a migration to. Not whether the new platform works, which is expected, but whether the old one is gone.
Harry Le is a cloud engineer at Coder Trove. Our Azure and cloud engineering practice runs migration, platform engineering and operations across Azure and AWS.