The replacement project went well. The new system is in production, users have moved across, the steering committee has formally closed it. The old system was to be switched off “once the last remaining uses have migrated”. Two years later, it is still running. Nobody uses it to do their job any more, but a monthly report still draws figures from it, one department believes history may have to be retrieved from it in the event of an inspection, and an interface still drops a file somewhere.

It is not free. It consumes licences, backups, a maintenance window, an ageing technical foundation, patches that must be applied without ever being fully testable, and it produces the same audit observation every year. Above all, nobody can name the person who today holds the authority to turn it off.

This scenario is not a governance accident: it is the default behaviour of every organisation. Application portfolios grow monotonically. Every year adds systems; almost none removes any. The cause is neither negligence nor a lack of method. It is that switching a system off is the only lifecycle activity with no sponsor, no budget line, and no visible benefit to whoever would have to fund it. Decommissioning rarely fails for technical reasons. It fails because the right to switch off was never assigned to anyone, and because the terms of retirement were never written at the moment they cost nothing: at commissioning.

The portfolio never shrinks

The asymmetry is structural, and worth examining closely, because it explains why the problem is immune to good intentions.

Putting a system into service has a sponsor, a business case, a stated benefit and an opening date. Taking one out has none of that. The benefit is diffuse — some licence cost, some operations effort, slightly less exposed surface — and it lands on budgets other than the one that will pay for the work. The cost is concentrated and immediate: a project, run by teams already busy elsewhere, on a system nobody masters any more. And the risk is asymmetric: succeeding earns nothing visible, breaking something is noticed at once.

Every individual trade-off is therefore perfectly rational. Deferring the shutdown is always the prudent choice, for each person, taken in isolation. It is the sum of these locally sound decisions that produces a portfolio which only ever grows — which is why no amount of exhortation to “clean things up” changes anything.

What that accumulation actually costs does not appear on a budget line either. Licences and infrastructure are the measurable part, and the smaller one. The dominant cost is a cost of attention: every system in the portfolio takes a share of the capacity to apply patches, to answer audits, to keep a skill alive, to test interfaces whenever something adjacent changes. It also takes a share of the capacity to decide: the wider the portfolio, the more expensive a transformation becomes merely to scope.

The most expensive residual systems are, in fact, precisely the ones described as “costing almost nothing to leave running”. They carry an end-of-life technical foundation, a skill that is disappearing, and a dependency nobody remembers. Their cost is not in day-to-day operation: it is in the day someone has to touch them.

The four locks

When an organisation genuinely attempts to switch a system off, it meets four distinct obstacles. Confusing them is the main reason rationalisation campaigns stop after the first difficult case.

The usage lock. Nobody knows who still uses it. Declared usage and actual usage always diverge, and residual usage is almost never the system’s main function: it is a report, an export, an occasional end-of-quarter consultation. As long as this question stays open, the precautionary answer — “not yet” — is unbeatable, because it asks no one to take a risk. Measuring effective usage through connections, traffic and reads actually observed turns a vague fear into a short list of identified people to talk to. It is the precondition for everything else.

The dependency lock. A system nobody officially calls may still feed three other applications through exchanges no one catalogued: a file dropped overnight, a direct database read, a shared table. The retirement project then discovers the dependency map that was never maintained — and discovers it at the worst possible moment, once the effort is committed and the date announced.

The data lock. This is the heaviest, and the one retirement plans anticipate least. Switching off an application is not deleting its data, and three very different questions are constantly conflated here: what must be retained under a retention obligation, what must remain accessible to the business because it forms the history of a live case, and what must simply be readable in the event of an inspection or a dispute. Each carries a different horizon, a different form and a different cost.

Conflating them invariably produces the same non-decision: keep everything, and keep the application running so it can be read. That is how a system becomes immortal — not because it delivers a service, but because it serves as a viewer for its own data. The clean treatment is to separate the data from the application that produced it: extract it into a documented, self-describing form, carrying its business meaning, rather than as a raw dump of tables whose columns nobody will be able to interpret in five years. An archive whose meaning has been lost is not an archive: it is storage volume that provides reassurance.

One point is regularly left out: a retention obligation also has an end date. Past that term, keeping data is no longer the prudent position — it is a risk nobody has examined, particularly where the data concerns individuals. “Keep everything, you never know” is not a retention policy.

The accountability lock. The repository does name an owner, but often it is someone who inherited the system and has no mandate to decide its end. Those who would benefit from the shutdown — operations, security, architecture — cannot decide it. The one who could decide has no interest of their own in it. In that configuration, the default answer to “can we switch it off?” will always be no, because no is free and yes is risky.

Retirement belongs in the commissioning

The cheapest moment to decide how a system stops is the moment it starts. At commissioning, dependencies are known, data structures are documented, the team that designed them is present, and nobody is attached to it yet.

What should be written at that point takes only a few lines: the expected lifespan or, failing that, the date at which the question will be revisited; who holds the retirement decision; in what form the data will be extracted when the time comes; and which interfaces are contractual — therefore supported and known — as opposed to merely tolerated.

The direct formulation is useful in a committee: a system put into service with no documented answer to “how does this end?” is a system placed under an implicit commitment to perpetual maintenance. Nobody validated that commitment, and everybody will pay for it.

The corollary concerns replacement projects, and it is more demanding than it looks: retiring the old system must sit inside the scope, the budget and the closure criteria of the project that replaces it — not as a later phase, but as the condition that ends the project. A migration project that finishes when the new system works has not migrated: it has duplicated, and it leaves behind an invoice nobody will carry. The clean rule is blunt but healthy: the project is done when the old system is off, not when the new one is on. It changes the estimate and shifts the sponsor’s trade-off — which is precisely why it is so often left out.

Shrinking an existing portfolio

That leaves the ordinary case: inheriting an established portfolio, with its residual systems and none of these clauses.

The first decision is not to start with the biggest. Start where the ratio of effort to constraint released is best, and above all where you will learn: one retirement carried through to the end establishes the method and, more importantly, demonstrates to the organisation that it can be done. Until that precedent exists, every subsequent candidate will look too risky.

Then classify residual systems by the reason they are still running, because each reason calls for different treatment. If genuine business usage remains, it is a functional migration: a project, to be scoped as such. If the system is now only a means of reaching data, this is not an application problem but an archiving problem, and the answer is extraction, not perpetuation. If it still feeds an interface, it is a producer substitution. And if no usage can be identified but it is kept running out of caution, then nothing is missing except a decision — and someone to take it.

That last case, the most common, is handled through announced extinction: publish a retirement date, notify identified consumers, then interrupt the service reversibly before shutting it down for good. A scheduled, announced outage, run outside sensitive periods and with a restore plan, is the only reliable way to discover a use nobody declared. It surfaces silent users within hours, where six months of written requests will have produced no reply at all.

Two rules complete the mechanism. The first: silence means consent. A retirement request sent to identified consumers, with a deadline, and unanswered when that deadline passes, is an agreement — otherwise the process stays hostage to those who do not reply. The second: make the released capacity visible. If the savings dissolve into the general operations budget, nobody will fund the next retirement. Explicitly attaching what is freed — licences, infrastructure, and above all team time — to the next retirement is what makes the practice self-sustaining.

The indicators follow the same logic. The number of applications decommissioned, on its own, says nothing. What informs: how many systems have no owner able to decide their shutdown, how many run solely to provide access to data, how many sit on a technical foundation that is out of support, and — the most honest measure — how many systems left the portfolio this year compared with how many entered it.

What architecture must hold

Architecture’s role is not to run the retirements, but to make it possible for them to be decided.

That means holding the exit-clause rule at every commissioning; keeping ownership and dependency information fresh enough that a retirement can be scoped in days rather than months; arbitrating the retirement queue as a portfolio, with stated priorities, rather than case by case; and requiring of every replacement project that the shutdown sits within its scope.

It also means contradicting, every time it is uttered, the sentence that protects residual systems: “it costs next to nothing anyway”. No system costs nothing. Each one takes a share of attention, and attention is the scarcest resource an IT organisation has.

Stopping is a capability

An organisation’s capacity to transform is measured as much by what it can stop as by what it can start. A portfolio that only grows describes an organisation devoting an increasing share of its means to maintaining decisions taken by people who have left, for reasons nobody can any longer reconstruct.

Decommissioning is neither housekeeping nor an end-of-project task. It is the moment an organisation reclaims capacity it had lent out with no end date. And like every architectural decision, it costs almost nothing when taken at the right moment — at commissioning, in a single clause — and becomes a project when taken ten years too late.