Legacy Modernisation — The Programme That Never Ends
The programme that was supposed to retire the legacy became, in time, legacy itself.
The Promise and the Pattern
Every legacy modernisation programme begins with the same conviction: that the organisation’s ageing technology estate is the principal obstacle to progress, and that replacing it will unlock a new era of agility, efficiency, and competitive capability. The business case writes itself. The current systems are expensive to maintain, difficult to change, dependent on a shrinking pool of specialists, and increasingly incompatible with the digital capabilities the market demands.
The logic is sound. The pattern that follows, however, is remarkably consistent — and remarkably different from what the logic promises.
In my experience across multiple sectors, the trajectory of large-scale legacy modernisation is almost invariant. The first twelve months are consumed by discovery: the estate turns out to be larger, more interconnected, and more poorly documented than anyone anticipated. The second year sees scope revisions, as the programme confronts the reality that replacing core systems means replacing the business processes embedded within them — processes that no one fully understands and that have accumulated decades of implicit business logic. By year three, the programme has become an institution in its own right, with its own governance, its own politics, and its own momentum — but often with surprisingly little production deployment to show for the investment.
The question worth asking is not why individual programmes fail, but why this pattern is so persistent.
Why Legacy Is Not Principally a Technology Problem
The fundamental misdiagnosis at the heart of most legacy modernisation programmes is the assumption that legacy is a technology condition. It is not. Legacy is an organisational condition. The technology is merely its most visible symptom.
When an organisation describes a system as “legacy,” what it is actually describing is a system that has become so deeply embedded in organisational processes, decision-making structures, and institutional knowledge that it can no longer be changed at a pace that matches the organisation’s strategic needs. The technology may indeed be old. But the reason it cannot be replaced is not primarily technical — it is because the organisation has wrapped itself around the system in ways that make separation extraordinarily difficult.
Every workaround, every manual process that compensates for a system limitation, every spreadsheet that bridges two systems, every piece of tribal knowledge held by a specialist who has operated the system for fifteen years — these are not incidental. They are the connective tissue of the organisation’s operating model. Replacing the system without addressing this connective tissue simply moves the problem from one technology platform to another.
The Three Traps
Legacy modernisation programmes consistently fall into three structural traps that explain their persistent failure to deliver on time, on budget, or on promise.
The scope trap. The programme begins with a defined scope — replace system X with platform Y. But as discovery progresses, the programme discovers that system X is connected to systems A through W in ways that were undocumented, unexpected, and often inexplicable. Each connection represents a business process, a data flow, or an integration that must be preserved, redesigned, or deliberately retired. The scope does not creep incrementally. It expands in step changes as each layer of dependency is uncovered.
The knowledge trap. The business logic embedded in legacy systems is often undocumented and understood only by individuals who have worked with the systems for years. When the programme attempts to specify requirements for the replacement, it discovers that no one can fully articulate what the current system does. The specification process becomes an archaeology exercise, and the archaeologists — the long-tenured specialists — become the programme’s critical path. Their knowledge is essential but difficult to codify, and the programme becomes dependent on individuals it cannot replace.
The parallel running trap. Because the risk of switching from old to new is perceived as high, organisations insist on extended periods of parallel running — operating both the legacy and replacement systems simultaneously. This doubles the operational burden, extends the timeline, and creates a perverse incentive: the longer parallel running continues, the more the organisation adapts to operating both systems, and the less urgent the cutover becomes. I have observed programmes where parallel running, originally planned for three months, extended to two years — by which point the replacement system itself required its first round of upgrades.
The programme that was supposed to retire the legacy became, in time, legacy itself.
What the Textbooks Leave Out
The standard prescriptions for legacy modernisation — phased migration, strangler patterns, iterative replacement — are technically sound. What they consistently underestimate is the human and organisational dimension of the problem.
Legacy systems persist not because organisations lack the technology to replace them, but because they lack the organisational will to confront the business change that replacement requires. Replacing a core system means making explicit the implicit — documenting undocumented processes, challenging workarounds that have become standard practice, and forcing decisions about business rules that the organisation has avoided for years by leaving them embedded in code that no one reads.
This is uncomfortable work. It surfaces disagreements that the organisation has managed by not resolving them. It exposes practices that work but that no one would have designed deliberately. It requires people to articulate knowledge they have never had to explain, and to accept that their expertise — their irreplaceability — may not survive the transition.
The programmes that make genuine progress are those that treat legacy modernisation as an organisational change programme with a technology component, not the reverse. They invest as heavily in business process redesign, knowledge capture, and change management as they do in platform engineering. They accept that the timeline is determined by the organisation’s capacity to absorb change, not by the technology team’s capacity to deliver code.
The Honest Conversation
The most valuable thing a programme leader can do at the outset of a legacy modernisation is to have an honest conversation with the executive sponsor about what the programme actually is. It is not a technology replacement project. It is a multi-year organisational restructuring that happens to produce a new technology platform as one of its outputs. The business case must reflect this reality — not just the infrastructure savings and efficiency gains, but the cost of the organisational change required to realise them.
This conversation rarely happens, because it produces uncomfortable answers. The true cost is higher than the technology-only estimate. The timeline is longer. The benefits are less certain and more dependent on business decisions that the sponsor may not have the authority or appetite to make. But having this conversation early — and governing the programme accordingly — is the difference between a programme that delivers painful but genuine modernisation and one that joins the long list of legacy replacements that became, in time, legacy themselves.