I have worked on systems that were described, at the time they were built, as strategic investments. Modern. Flexible. Future-proof. The people who built them — and I was often among them — genuinely believed that description. And then, a few years later, those same systems would appear on a programme agenda as the thing that needed to be replaced. The label had changed. The system, in most cases, had not.
That gap — between the confidence with which we build and the speed with which things become "legacy" — is one of the most consistent realities in a long career. Understanding why it happens changes how you approach the design, investment, and management of technology systems.
The First Time I Noticed It
Early in my career, I worked on a system that was considered cutting-edge at the time — well-architected, significant investment, clearly the right approach for the requirements as they were then understood. A few years later, I sat in a meeting where someone referred to it as "an old system we need to replace."
What struck me was that nothing about the system itself had fundamentally changed. It was doing what it had been designed to do, doing it reliably. But everything around it had moved: the business needed things the system had not been designed for, the integration landscape had grown considerably more complex, the technology standards the organisation was using elsewhere had evolved. The system had not aged badly. The world it was operating in had simply moved on.
Systems do not become legacy because they age. They become legacy because the environment around them changes — and that environment changes faster, and less predictably, than the systems we build into it.
Why It Keeps Happening
The causes are consistent across sectors, system types, and decades. Each is individually unremarkable. Together, they explain why every system, regardless of the quality of its original design, moves through the same lifecycle.
The Mistake Organisations Make
The most common organisational response to legacy systems is to treat them as a problem to eliminate — to invest in replacement programmes on the assumption that if the old system can be removed, the organisation will be free of the "legacy problem." This framing is wrong in a specific and important way.
The system being replaced is not the problem. The dynamic that made it legacy is the problem — and that dynamic will operate on the replacement system with exactly the same force. Today's modern platform is tomorrow's legacy. The replacement that took three years and significant investment will, in time, appear on its own programme agenda as the thing that needs to be replaced.
Organisations that focus on replacing legacy systems, rather than managing the lifecycle dynamic that creates them, are running a race they cannot win. The finish line moves at the same speed as the runners.
A More Useful Framing
The more productive question is not how to eliminate legacy, but how to manage the inevitability of it. That reframe leads to a different set of decisions at the design stage and a different approach to system management throughout the lifecycle.
Designing for change — limiting unnecessary complexity, avoiding excessive customisation, keeping interfaces clean and documented, accepting that the system will need to evolve — does not prevent a system from eventually becoming legacy. But it determines how quickly that happens, how expensive it is to manage, and how difficult replacement becomes when it is eventually necessary.
Every system has a lifecycle. The problem is not that systems eventually become legacy — that is as inevitable as the passage of time. The problem is expecting that they won't, and making decisions as if the current system will meet the organisation's needs indefinitely.
The most honest thing you can say about any system you are currently building is: one day, someone will describe this as legacy. Design it so that day is as far away as possible — and so that when it comes, the transition is as manageable as it can be.