A replaced system is still running two years after its replacement went live. Why does decommissioning fail, and what makes it happen?

Why it fails

1. Unknown consumers. Nobody can prove the system is unused, and the cost of being wrong — breaking something — dominates the benefit of switching it off. So it stays on, indefinitely, out of caution.

2. No owner. Decommissioning is unglamorous work with no feature output. Without a named owner and protected capacity, it loses to every alternative on every sprint.

3. It was never a deliverable. The migration project's scope ended at "new system live", so the old system was somebody's future problem.

4. Residual dependencies. A reporting job, an integration, a support tool, an audit query. Each is small and each blocks the switch-off.

5. Data retention obligations that nobody has separated from the running system, so the system stays alive to hold data that could be archived.

What makes it happen

1. Evidence of non-use. Traffic and query logging over an extended period, showing what still calls it and what does not. This directly addresses the primary blocker — most fear of decommissioning is fear of unknown consumers, which is an information problem with a technical solution.

2. Progressive shutdown rather than a switch. Read-only mode, then blocked for a period with the ability to restore quickly, then stopped, then removed. Each stage is reversible and each surfaces a consumer safely. This is the technique that converts a risky irreversible action into a sequence of measurements.

3. Data separated from the system. Archive what must be retained into a form that does not require the application to be running — which frequently removes the only remaining reason it exists.

4. A named owner with a date, and the work funded rather than fitted around other priorities.

5. Cost visibility. Attributing the running cost — licences, infrastructure, support, security patching, and the on-call burden — to an owner creates the incentive that caution otherwise overrides.

The organisational framing

Decommissioning must be a deliverable of the migration, not a follow-on. A slice is not migrated until the old path is removed — anything short of that is coexistence, and coexistence is where the business case goes to die.

Making that a rule at the start of the programme is far easier than arguing for the work two years later, when the benefit is diffuse and the risk feels concrete.