Legacy Is a Decision You Make Every Year
The register creates the appearance of management without the substance of decision.
The Annual Renewal
Every organisation has a version of the same slide. It appears in the annual technology review, usually around slide fourteen: a list of platforms colour-coded by age, with the oldest glowing an alarming red. The commentary is always the same. These are legacy systems. They were decisions made by people who are no longer here, and they constrain what we can do now. The language frames the problem as inheritance — something done to us by a previous generation of leaders, a burden we carry rather than one we chose.
The framing is comforting and almost entirely dishonest.
The Renewal Nobody Admits
Legacy is not inherited once. It is renewed annually, every time a modernisation programme loses the funding contest to a feature release, every time an exit date slips without consequence, every time a risk register entry ages from red to a comfortable amber because nothing has yet caught fire. The honest description of most legacy estates is not that they were left to us but that we decided, year after year, to keep them — and then described the result as someone else’s fault.
This matters because diagnosis determines treatment. If legacy is an inheritance, the response is a one-off transformation: a migration programme, a platform replacement, a multi-year remediation. If legacy is a decision renewed annually, the response is a change to the governance mechanism that keeps renewing it.
What Technical Debt Language Did — and Then Stopped Doing
The technical debt metaphor, when Ward Cunningham first articulated it, was a genuine contribution. It gave technology leaders a financial language for a problem that business leaders could not otherwise see: the accumulated cost of shortcuts, the compounding interest on deferred maintenance, the difference between moving fast now and moving at all later.
But the metaphor has run past its usefulness. In most organisations I encounter, technical debt has become a register — a long, carefully categorised list of known problems, scored by severity, reviewed quarterly, and funded almost never. The register creates the appearance of management without the substance of decision. It lets the organisation say we know about this without ever answering the harder question: what are we going to do about it?
The debt metaphor also carries a hidden assumption that distorts governance. Financial debt is incurred at a point in time and then serviced or retired. Platform decay does not work this way. It is not a loan taken out in 2011; it is a cost incurred again every year the platform remains in production. The interest is not hypothetical — it is measured in incident load, in change-delivery friction, in the shrinking pool of engineers who understand the system, in the security exposure that accumulates as patching windows widen. These are operating costs, not a balance-sheet liability, and treating them as the latter means they never compete fairly against revenue-generating work.
Carrying Costs, Not Debt
The shift required is from debt language to carrying-cost language. Every platform in a portfolio has a carrying cost: the total operational burden of keeping it alive, functional, secure, and capable of absorbing the changes the business needs. For a modern, well-maintained platform, the carrying cost is low and predictable. For an ageing platform that has been starved of investment for years, the carrying cost is high, volatile, and rising — and it is largely invisible because it is dispersed across incident management, manual workarounds, integration complexity, and the opportunity cost of engineers who spend their time nursing rather than building.
A chief technology officer who calculates the fully loaded carrying cost of a single ageing platform — the incidents, the workarounds, the integration adapters, the specialist contractors retained because nobody else can maintain the codebase — is often startled by the figure. It is frequently higher than the annualised cost of replacement. But because it is dispersed across a dozen budget lines, it has never appeared as a single number in a portfolio conversation.
Making carrying costs visible is the first governance intervention. Not in a register that sits alongside the investment portfolio, but inside the portfolio itself, as a standing line item. The cost of keeping Platform X alive this year is not a debt to be discussed; it is expenditure to be justified. And the justification requires answering a question that most portfolio governance avoids entirely.
Deliberate or Default?
The question is simple, and it should be asked of every ageing platform annually: are we keeping this deliberately, or by default?
Deliberate retention is a strategy. It says: we have examined this platform’s carrying cost, we understand its trajectory, and we have decided — consciously, with full sight of the trade-offs — that the cost of replacement exceeds the cost of retention for the foreseeable future. That is a legitimate portfolio decision. Organisations make it well when they are honest about what “foreseeable” means and when they attach a review trigger — a cost threshold, a compliance deadline, a capability gap — that forces the question to be re-asked.
Default retention is not a strategy. It is the absence of one. We have all seen the pattern: a platform whose exit was scheduled for 2019, rescheduled to 2021 when the programme overran, quietly dropped from the roadmap in 2022 when the sponsoring executive moved on, and now sitting in the portfolio with no planned retirement at all — still running, still absorbing a significant share of the operations team’s incident load, still requiring monthly manual reconciliation because its batch outputs cannot be consumed by the downstream integration layer built three years after it. Nobody decided to keep it. Nobody decided anything. The decision was made by the absence of a decision, which is the way most legacy decisions are actually made.
The gap between deliberate and default is where most legacy accumulates. Not because organisations lack the technical capability to modernise, and not because the economics are genuinely prohibitive, but because the governance mechanism is designed to fund new things and to tolerate old ones. The asymmetry is structural: a new feature has a sponsor, a business case, a delivery date, and a success metric. A platform retirement has a cost, a risk, a disruption estimate, and no revenue line. In every portfolio prioritisation framework I have seen, the new feature wins — not because it is more valuable, but because the framework is built to compare investments, not to weigh investments against the compounding cost of inaction.
The Forcing Function Nobody Expected
There is a reason this question has acquired fresh urgency in 2024, and it has nothing to do with the annual rhythm of technology strategy reviews. The accelerating conversation around enterprise AI readiness has quietly repriced the entire legacy estate. Platforms that cannot expose their data through modern interfaces, that cannot support the integration patterns emerging AI capabilities require, that sit behind proprietary protocols and batch-era architectures, are no longer merely expensive to maintain — they are obstacles to participation in what is rapidly becoming the next generation of enterprise capability. The AI-readiness gap is not a future concern; it is a present one, and it is repricing the “default retention” decision in real time. An organisation that was comfortable carrying a legacy platform at its current cost may find that cost has materially increased once the platform’s inability to participate in AI-enabled workflows is factored in — not as a theoretical future loss, but as a competitive disadvantage accumulating now.
Governance That Asks the Right Question
The practical change is smaller than it sounds. It does not require a new framework, a new operating model, or a transformation programme. It requires three adjustments to the way portfolio governance already works.
First, carrying costs are surfaced as a standing portfolio line, not buried in operational budgets. Every platform above a defined age or complexity threshold has its annual carrying cost calculated, presented alongside the investment portfolio, and scrutinised with the same rigour.
Second, the deliberate-or-default question is asked annually, formally, of every platform on that list. The answer is documented, owned by a named individual, and reviewed. “We are keeping this by default” is not an acceptable answer — it is a flag that a decision has not been made.
Third, modernisation funding is allocated as a standing portfolio allocation — a ring-fenced percentage that does not compete with feature investment in the annual cycle. The percentage can be debated; the principle cannot. As long as platform retirement must win a beauty contest against revenue-generating features every year, it will lose every year, and the legacy estate will grow by exactly the amount the organisation pretends to be managing.
Legacy is not what was left to you. It is what you decided to keep — and the decision is made again, quietly, every time the funding cycle completes without addressing it.
None of this is technically difficult. The difficulty is cultural: it requires organisations to stop describing legacy as an inheritance and to start describing it as a choice. That shift is uncomfortable because it moves accountability from the past to the present, from unnamed predecessors to the people sitting in this year’s portfolio review. But it is the only framing that produces a different outcome. An inheritance is endured. A choice can be changed.