Progressive Shutdown

Decommissioning stalls because nobody can prove a system is unused, and the cost of being wrong dominates the benefit of switching it off. So it stays running indefinitely, out of caution rather than need.

Progressive shutdown removes the asymmetry by converting an irreversible action into a sequence of reversible measurements:

1. Instrument and observe. Log every access — caller, endpoint, frequency — over a period long enough to include monthly and quarterly processes. This directly addresses the primary blocker, because most fear of decommissioning is fear of unknown consumers, which is an information problem.
2. Read-only. Writes are refused with a clear error. Anything still writing surfaces immediately, and the system continues serving reads.
3. Blocked, with fast restore. Access is refused for a defined period — a day, then a week — with the ability to restore in minutes. Consumers that survived the earlier stages appear here.
4. Stopped but retained. The system is off, the data and configuration are kept, restoration is possible though slower.
5. Removed, after a retention period, with any obligated data archived independently.

Each stage is reversible, and each surfaces a consumer at a cost measured in minutes rather than in an outage.

Why the sequence works

The stages are ordered by how much they break. A consumer that writes is found at stage two; a consumer that reads occasionally is found at stage three; a consumer that runs quarterly is found by the observation window or by stage three's duration.

Nothing is discovered by a permanent outage, which is the outcome the caution was protecting against.

Implementation patterns

• Announce each stage, with the date and how to object — so consumers can identify themselves rather than being discovered.
• Separate the data from the system. Archive what must be retained into a form that does not require the application to run, which frequently removes the only remaining reason it exists.
• Attribute the running cost — licences, infrastructure, support, patching, on-call — to an owner, which creates the incentive that caution otherwise overrides.
• A named owner and a date, with the work funded rather than fitted around other priorities.
• Make it a deliverable of the migration, not a follow-on. A slice is not migrated until the old path is removed.

Industry example

Systems still running years after their replacement went live are the norm rather than the exception, and the causes are consistent: unknown consumers, no owner, decommissioning never scoped as a deliverable, small residual dependencies each blocking the switch, and retention obligations tied to the running system.

The organisations that clear these successfully use exactly this staged approach, and report that the observation stage alone usually reveals that the majority of expected consumers no longer exist — the fear was real and the dependency was not.

Failure scenarios

• Skipping observation and going straight to blocked, which produces the breakage the caution predicted and sets the programme back.
• An observation window shorter than the longest business cycle, missing quarterly and annual processes.
• No fast restore at the blocked stage, so a discovered consumer becomes an incident rather than a finding.
• Data left in the system, so retention obligations keep it alive after every consumer is gone.
• No owner, so the sequence stalls at whichever stage requires the next decision.

Trade-offs

Progressive shutdown takes months of elapsed time and requires someone to shepherd it, during which the system continues to cost money. A confident immediate switch-off is faster when you genuinely know the consumers.

The staged approach is what you do when you do not know — which is the normal case for anything old enough to be worth decommissioning.

Interview question

"A system was replaced two years ago and is still running because nobody can prove it is unused. Walk me through how you would switch it off — and tell me what you would do differently in the next migration so this does not recur."