A cloud migration is finished when the old environment is switched off and the data centre contract ends, because that is where the business case saving comes from. Plan decommissioning from the start of the programme, with a disposition for every workload and a committed data centre exit date.
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. The migration gets declared finished when the new environment is switched on, and the old one keeps running. Those two milestones are 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. Each 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.
Every workload in the estate gets a disposition before anything moves: rehost, replatform, refactor or retire. Retire is a first-class outcome, and on most estates it is the right answer for more workloads than anyone expects. A system nobody can name an owner for is a retirement candidate until someone claims it.
The migration waves are then ordered so infrastructure can 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, so you are not running everything until the 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 someone has to answer for the date, the awkward tail workloads get decisions instead of deferrals.
The most common blocker at the end is data nobody wants to move and nobody is willing to delete. Migrating it as it stands is rarely the answer. Cold storage tiers exist for this: contracts, logs and historical records move to archive storage at a fraction of the cost of running the server they lived on, and the retention policies get documented in the process. The server retires and the retention obligation is still 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.
When the old environment is switched off and its hosting contracts end. Go-live on the new platform is a milestone on the way.
It is one of the four dispositions, alongside rehost, replatform and refactor: the workload is switched off and not moved. Systems with no identifiable owner are the first candidates.
Move it to a cold or archive storage tier with a documented retention policy, then retire the server it lived on.
Often because the old data centre is still running alongside the new platform. Once it is gone, the next savings are inside the cloud estate itself, covered in where avoidable cloud spend hides.
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.