Consultancy service
Platform rescue and controlled decommissioning
Finding what is really connected, what can safely be removed, what must be retained, and how to move from messy inherited systems to governed, supportable platforms.
The problem
Legacy platforms survive because nobody can prove they are safe to switch off. They cost money, carry risk and consume attention, yet every retirement plan stalls on the same question: what still depends on this?
Rescue and retirement are the same discipline. Both start by finding what is really connected, and both end with evidence that the change was controlled.
Typical situations
- A legacy platform that everyone wants gone and nobody dares touch.
- Stale objects, unknown service accounts and undocumented scheduled tasks.
- An inherited system that must be stabilised before it can be modernised or retired.
- Decommissioning that has to stand up to audit afterwards.
- Cost and risk reduction targets attached to old infrastructure.
How the work runs
- 01
Inventory from the platform itself
Sessions, applications, connections, service accounts and data paths, gathered read-only.
- 02
Observe real usage
A window long enough to catch month-end and quarter-end processing, not just a quiet fortnight.
- 03
Map and decide
Every dependency gets a named owner and a decision: migrate, replace, retire, or accept the loss in writing.
- 04
Reduce in stages
Access restricted with a fast way back, so anything missed announces itself while the platform can still be restored.
- 05
Switch off and evidence
Retain the record, then release the licences, the hardware and the support contract.
Risks and decisions
Risks to control
- Workloads that only appear at month-end or quarter-end, missed by a short observation window.
- Service accounts created for the platform and reused by systems nobody connected to it.
- A switch-off with no tested way back.
- Idleness mistaken for absence because batch, failover and break-glass roles were never checked.
- A retirement nobody can defend to an auditor a year later.
Decisions to settle
- When the observation window has proved enough.
- What happens to every dependency, decided by a named owner rather than left to the switch-off to discover.
- What access reduces first, so anything missed announces itself safely.
- What residual risk is accepted, and who is entitled to accept it.
- When the platform is genuinely retired, evidenced rather than assumed.
What you get back
- 01Platform inventory and usage record
- 02Dependency map with named owners
- 03Decision log: migrate, replace, retire or accept
- 04Staged reduction plan with restore points
- 05Switch-off record and sign-offs
- 06Decommissioning evidence pack
Delivered evidence
Featured enterprise engagement
AWS EUC modernisation: Windows 11 WorkSpaces built as code, legacy Citrix estate decommissioned
A major UK insurer needed to modernise an AWS EUC estate, replacing a legacy Citrix-on-EC2 developer desktop platform with a Windows 11 AWS WorkSpaces environment.
- Decommissioned the legacy Citrix / EC2 estate while preserving load-bearing FSx / DFS dependencies.
- Used AI-assisted methods during the modernisation and decommissioning phase to accelerate estate discovery, dependency mapping, documentation and implementation planning.
100%
80+
Zero
Reference material
Supporting evidence
