Cloud and EUC
Why a desktop migration is not finished when the users have moved
The last user moving to the new desktop platform is a milestone worth marking. It is not the finish line, and the work that remains decides what the whole migration was worth.
Every desktop migration has a day when the last user group moves. It is a real achievement: months of imaging, testing, communication and weekend work end with people signing in to the new platform and getting on with their jobs. The temptation to call the project finished at that moment is enormous, and in many estates that is exactly what happens.
The problem is that the definition of done was written about users, not about the platform. Moving people proves the new environment works. It proves nothing about whether the old one can be switched off, and the gap between those two statements is where migrations quietly lose their value.
Two different finish lines
User migration and platform completion answer different questions, and it helps to see them side by side.
Users moved against platform complete
| Question | Users moved proves | Completion requires |
|---|---|---|
| Sessions | People can sign in and work | Every workload has a supported home on the new platform |
| Dependencies | The new platform reaches what it needs | Nothing still depends on the old platform |
| Management | Devices appear in the new tooling | One management plane, with the old one retired |
| Support | The service desk can log tickets | Runbooks, monitoring and ownership updated to the new world |
| Cost | The new platform is being paid for | The old platform has stopped being paid for |
One management plane
The clearest sign of an unfinished migration is management tooling running split-brain. Devices answer to two consoles, each holding a partial truth. Policy exists twice and agrees mostly. Patching reports green in one system and unknown in the other, and every audit question starts with working out which console to believe.
Collapsing to one management plane is a completion decision in its own right: agreeing which system is authoritative, moving the last objects out of the old one, and retiring it deliberately rather than leaving it as a second opinion. A useful test is to ask which console the service desk opens first. If the answer is still the old one, the migration has not moved the operational centre of gravity.
What is usually still running
Look at an estate a month after the last user moved and the old platform is rarely quiet. Commonly you will find:
- Legacy application hosts still serving published apps to a handful of processes.
- File, profile and print paths that resolve through the old infrastructure.
- Management tooling running split-brain: two consoles, two sources of truth, two patch cycles.
- Service accounts and scheduled jobs that lived on the old estate and were never rehomed.
- A rollback capability that nobody has formally closed, so the old estate is still production.
- Licences and support contracts renewing because cancellation was never anyone's task.
Deciding when rollback is over
While rollback stays open, the old platform must be maintained to production standard: patched, backed up, monitored and paid for. That is the correct cost of an open rollback decision. The mistake is not having the window; it is nobody owning the decision to close it. A useful test is to ask who is entitled to declare rollback finished, and whether they know it is their decision.
“A migration is finished when the old platform is no longer anyone's answer to anything.”
Support has to move too
A platform is not migrated until the people who support it have migrated with it. Runbooks that still describe the old estate, monitoring that still watches the old hosts, on-call rotas that still assume the old failure modes: each is a small operational debt that surfaces at the worst possible moment. Commonly the service desk discovers a migration is unfinished before anyone else does, because tickets keep routing to queues and procedures that no longer match reality.
The transfer is unglamorous: rewrite the runbooks against the new platform, re-point monitoring and alerting, retire the old dashboards, and walk the support team through the new failure modes before they meet them live. None of it is difficult. All of it is easy to leave undone once the project team has gone.
The completion sequence
The work after users move has a shape, and it runs in order.
From users moved to platform complete
- 01Validate operationsProve the new platform under real load: month-end, printing, peripherals, remote access and the awkward applications, with issues owned and closed rather than tolerated.
- 02Re-point what still looks backwardsFind every path, shortcut, script and integration that still resolves through the old estate, and give each one a new home or a written exception.
- 03Close the rollback decisionAgree, in writing, the date after which the old platform is no longer a fallback, and record who accepted that.
- 04Reduce the legacy estate in stagesRestrict, pause and switch off with checkpoints and a fast way back, exactly as a controlled decommission deserves.
- 05Evidence and hand overRetire the old tooling, close the contracts, retain the evidence pack and hand operations one platform, not one and a half.
Why this phase gets skipped
The reasons are organisational rather than technical. The project team disbands at go-live. The budget line closes. The energy moves to the next initiative. One risk is that the people who understood the old estate leave the project in the same week the users move, taking the dependency knowledge with them.
The fix is structural: treat completion as a first-class workstream with its own owner, its own plan and its own definition of done, agreed before the first user moves rather than improvised after the last one. If completion has no owner, the go-live celebration becomes the project's final act by default.
Completion is real when
- One management plane runs the estate, and the old console is retired, not resting.
- No path, script, integration or shortcut resolves through the legacy platform.
- The rollback decision is formally closed, with a name and a date against it.
- Support operates from runbooks, monitoring and ownership written for the new platform.
- Old licences, hardware and support contracts are cancelled, with the evidence retained.
The reduction half of this work is a controlled decommission in its own right. I have written separately about decommissioning legacy EUC platforms, and the decommissioning evidence checklist describes the record that phase should leave behind.
