An application marked for retirement is switched off after its users are migrated. Nobody cuts the 14 interfaces that fed it or read from it. What happens over the following year?

Week one, in sequence

Jobs that wrote to the retired system begin failing. Some raise alerts owned by teams who no longer know what the target was; others fail silently, because a file transfer to a directory nobody reads produces no error at all. The distinction between the two decides everything that follows, and most estates have both.

Where the failure is visible, an engineer under pressure does the fastest thing: disables the job, or adds an exception so the pipeline continues. That is now a permanent decision made in ten minutes by someone without the context to make it.

Where it amplifies

• Downstream systems keep consuming the last data the retired system produced. A reference file, a nightly extract, a cached lookup: the data stops updating and nothing announces it. Six months later a report is wrong and the investigation is genuinely hard, because the pipeline is green and the data is stale rather than missing.
• The savings do not arrive. The licence, the database, the middleware route, the monitoring and the certificates all still exist because each is referenced by something. Rationalisation programmes routinely identify savings and deliver a fraction of them, and this is the main mechanism: the application is off, the estate around it is not.
• The interfaces become undocumented obstacles. In two years, someone modernising an adjacent system finds 14 connections to a system nobody recognises, cannot establish whether anything depends on them, and leaves them alone. That is how an estate becomes unchangeable.
• Credentials and certificates outlive the system. A service account with production access to a machine nobody maintains is a security finding waiting to be filed.

What the user sees

Nothing, for months. Then a wrong number in a report, a reconciliation break, or a compliance question that cannot be answered because the source of a figure no longer exists. The absence of an immediate symptom is the entire problem: it is why the work is skipped, and why it is expensive when discovered.

What stops it

Not documentation. A mechanism:

• Define decommissioning as an interface-level activity, not an application-level one. The exit criterion is "zero remaining connections", evidenced by network flow data, not by a checklist someone ticked.
• Instrument before you switch off. Run the system for a period with logging on every inbound and outbound connection, and use that as the true list — the documented list is always shorter.
• Retire in the reverse order of the data flow: cut producers first, then the system, then consumers, so a broken link produces a loud failure at a known time.
• Keep it reversible for a defined window. Stop the application but leave its data restorable for 90 days, because the thing you missed usually surfaces within one reporting cycle.
• Track savings against a named cost line, since a saving nobody books is a saving nobody verifies, and the unclaimed licence is the evidence the work was not finished.

What would have to be true for it to self-heal

Only if every interface fails loudly and is owned. In an estate where all integration goes through one platform with per-route ownership and alerting, a dead endpoint is a paged incident within minutes and the cleanup is forced. That is the real argument for centralised integration — not efficiency, but that it makes the connections visible enough to remove. In an estate of point-to-point file transfers and scheduled scripts, nothing forces the discovery, and the debris is permanent.

Common weak answers

• "Document the interfaces before switching off." Documentation is the list you already have and it is always short. Observed traffic is the list that is true.
• "The alerts will tell us." Half of these failures are silent by construction: a write to a directory nobody reads, a message to a queue nobody drains.
• "Retire the application, then clean up later." Later has no owner and no budget line, which is why the savings never arrive and the debris becomes permanent.