Obsolescence is a portfolio problem

Every asset-intensive business already knows how to manage ageing assets. Track and bridge engineers do not wait for a structure to fail before inspecting it; they hold a register, a condition rating, a renewal profile, and a funded programme. The discipline is unremarkable — which makes it strange that the same organisations so often manage their application estates by anecdote.

The usual pattern looks like this. Somewhere in the estate a system drops out of vendor support, or the last person who understands it resigns, or an operating-system upgrade strands it. A project is raised, funded on its own merits, and delivered — or, more often, deferred, because on its own merits an upgrade with no new features never wins against anything. Multiply by a few hundred applications and a couple of decades and you have a estate whose true condition nobody can state, carrying risk that surfaces one outage at a time.

Why single-system thinking fails

The core mistake is treating obsolescence as a property of individual systems. It is not, for three reasons.

First, the risk is concentrated in the couplings, not the components. An ancient system that nothing depends on is a curiosity; a moderately old one wired into a dozen operational processes is a liability. You can only see coupling by looking across the estate.

Second, the economics only work in aggregate. Individually, most remediation projects fail any conventional business case — the benefit is the avoidance of a loss nobody has quantified. As a portfolio, the case writes itself: the cost of standing still, stated honestly, is usually the largest unfunded programme in the business.

Third, sequence matters more than selection. In a coupled estate the order of remediation determines the cost of it: replace the wrong system first and you pay for temporary interfaces you will throw away; sequence by dependency and each step makes the next cheaper. Sequencing is inherently a portfolio decision.

What managing it as a portfolio looks like

The mechanics are not exotic. An inventory that is actually complete, including the systems procurement never saw. A condition assessment per application — vendor and platform currency, support position, internal knowledge, technical health — paired with business criticality, so a small ugly system that schedules trains outranks a large tidy one that formats reports. A dependency map honest enough to show which risks travel together. And then a remediation roadmap: retire, replace, remediate or tolerate, sequenced by risk and dependency, funded as a programme rather than re-litigated one project at a time.

The output that matters most is not the roadmap document. It is that obsolescence becomes a standing, quantified position the executive owns — reviewed like any other asset class — instead of a background anxiety rediscovered at each incident. Engineering organisations extend this respect to their physical assets as a matter of course. The application estate, which increasingly operates those assets, deserves the same.