Cloud and EUC
Decommissioning legacy EUC platforms without breaking the business
Switching a platform off takes an afternoon. Proving that nothing important still depends on it is the real project, and it is the part most decommissioning plans leave out.
Legacy end-user computing platforms rarely die. They fade into a corner of the estate, still patched, still licensed, still quietly billing, because nobody can say with confidence that the last workload has left. Most organisations have at least one: the old Citrix farm, the terminal server nobody admits to owning, the virtual desktop pool kept alive for a single application.
The temptation is to treat decommissioning as a calendar event.
Nothing is ever quite unused
Platforms that have been around long enough become load-bearing for things that have nothing to do with their original purpose. Look closely at an old EUC estate and you will usually find:
- File shares and DFS paths that other systems still resolve through the old servers.
- Service accounts created for the platform and quietly reused far beyond it.
- Scheduled tasks and scripts running in sessions nobody has watched for years.
- Print queues, drive mappings and shortcuts baked into departmental documentation.
- One business-critical application that never appeared on any inventory, and so was never migrated.
None of this appears in a licence count. It appears on the first Monday morning after the switch-off.
Evidence before the switch-off
A safe decommission is a discovery exercise with an off switch at the end, not an off switch with hope attached.
The retirement pattern
- 01InventorySessions, applications, connections, service accounts and data paths, gathered read-only from the platform itself.
- 02ObserveWatch real usage over a window long enough to catch month-end and quarter-end processing, not just a quiet fortnight.
- 03Map and decideEvery dependency gets an owner and a decision: migrate, replace, retire, or accept the loss in writing.
- 04Reduce in stagesRestrict access with a fast way back, so anything missed announces itself while the platform can still be restored.
- 05Switch off and evidenceRetain the record, then release the licences, the hardware and the support contract.
The last ten per cent
Every retirement stalls in the same place: a handful of stubborn dependencies with unclear owners. This is where projects either stop, leaving the platform running for another two years, or push through blind. Neither is necessary. Stubborn dependencies almost always resolve once someone senior owns the decision and the residual risk is written down rather than whispered about.
“A platform is not decommissioned when it is switched off. It is decommissioned when nobody notices that it was.”
The discovery techniques involved are the same ones that decide whether a file migration holds together. I have covered that side of the problem in why file migrations fail before they start.
