Legacy systems aren’t the problem. The decisions made around them are.

Ask most people working in or around UK government technology what the biggest barrier to digital transformation is, and you will get some version of the same answer. Legacy systems. The forty-year-old mainframe. The COBOL codebase nobody left in the building fully understands. The integration that was built as a temporary workaround in 2003 and has been load-bearing ever since.

It is a reasonable answer. It is also, in most cases, the wrong one.

Legacy technology is real, and the cost of maintaining it is genuinely significant. But in nearly every institution where we have worked, the legacy system itself is not what is preventing modernisation. What is preventing it is the set of habits, assumptions, and incentive structures that have calcified around the system over time. The culture of managing risk by not deciding. The procurement reflex that reaches for the large incumbent rather than the right architectural approach. The governance process that conflates the size of a programme with its safety.

Fix the culture, and the technology problem becomes tractable. Leave the culture in place, and the technology problem will regenerate regardless of what you spend.

The rip-and-replace trap

The conventional response to legacy technology in government is a large-scale replacement programme. Identify the ageing system, procure a modern alternative, run a migration, decommission the old. The logic is intuitive. The track record is not encouraging.

The National Programme for IT in the NHS, abandoned in 2011 after roughly £10 billion of public expenditure. The Universal Credit programme, which spent years and significant resource working around integration constraints that were identifiable, and addressable, much earlier. These are not outliers. They are the predictable result of treating a complex sociotechnical problem as if it were primarily a procurement exercise.

The pattern is consistent. A large legacy replacement is scoped. The scope grows as the complexity of what the legacy system actually does becomes clearer. The timeline extends. The costs escalate. The institution becomes risk-averse about the programme itself, which makes it harder to change course when course needs changing. Eventually something gives: the programme is scaled back, restructured, or quietly retired.

The system that was supposed to be replaced is often still running.

What the financial services sector learned the hard way

This is not a problem unique to government. We have spent years working in financial services, an environment where legacy technology is at least as entrenched and the consequences of getting modernisation wrong are immediate and measurable.

The major UK banks are running core systems that, in several cases, predate the internet. The migration risk is real: moving money requires near-perfect reliability, and regulators will not accept a tolerance for failure that a consumer app might absorb without consequence. The instinct, for years, was the same as government’s: the system is too critical to touch, too complex to replace, too risky to modernise incrementally.

What changed was not the technology. It was the architectural philosophy. The institutions that have made genuine progress in financial services modernisation have largely done so by building around their legacy core rather than attempting to replace it in a single programme. They have wrapped ageing systems in modern APIs. They have separated the functions that need to move fast from the functions that need to be stable. They have identified the parts of the legacy estate that can be retired without touching the critical path, and done that first.

The result is not a clean modern architecture. It is a pragmatic one. But it works, it is governable, and it accumulates progress rather than resetting it every time a large programme fails.

Government can and should apply the same thinking. The principles transfer directly. The regulatory complexity is analogous. And crucially, the argument that the systems are too critical to modernise incrementally is the same argument that was made, and disproved, in financial services.

The decision culture problem

So why does government keep reaching for large replacement programmes if the evidence against them is so clear? The answer, in our experience, is not ignorance. Most senior technology leaders in the public sector understand the track record perfectly well.

The problem is structural. Large programmes are easier to justify through a business case than incremental modernisation. They generate clearer governance milestones. They are easier to explain to ministers and accounting officers. They fit the procurement frameworks that exist. Incremental modernisation, by contrast, requires sustained executive attention over a long period, a tolerance for visible complexity during the transition, and a willingness to make small decisions frequently rather than large decisions rarely.

That last point matters more than it might appear. Legacy systems do not become unmaintainable overnight. They accumulate technical debt through a long series of decisions, or non-decisions, each of which seemed reasonable at the time. The same process happens in reverse when you try to modernise: you make a series of small, low-risk changes, and over time the system becomes less brittle, better understood, and easier to evolve.

But this requires an organisation that is comfortable making frequent, visible decisions about technology. Many public sector institutions are not. The incentive is to defer, to seek further assurance, to commission another review. Each individual deferral is defensible. The cumulative effect is paralysis.

The institutions making genuine progress on legacy modernisation in the public sector tend to share a few characteristics that are worth naming directly.

They treat the discovery phase seriously. Before any modernisation work begins, they invest in properly understanding what the legacy system actually does, not what the documentation says it does. These are often different things. Critical business logic accumulates in legacy systems over decades, undocumented, because it was cheaper to build the workaround than to change the system. That logic needs to be surfaced before you can safely migrate away from it.

They separate stability from agility by design. Modern architecture allows you to run a stable, unchanging core alongside a more rapidly evolving set of services built on top of it. This is how most successful financial services modernisation has worked. The core does not need to move fast; it needs to be reliable. The services built on top of it can move at the pace the business requires. Getting this architectural boundary right is the most important technical decision in any legacy modernisation programme.

They build in small, reversible steps. The highest-risk moment in any legacy modernisation is the cutover: the point at which the old system is switched off and the new one takes over. Programmes that minimise the size of individual cutovers, by migrating one function at a time rather than the whole system, are significantly less likely to fail catastrophically. This is not a novel observation. It is a principle that the technology industry has understood for twenty years and that government programmes continue to ignore.

They measure what matters during the transition. Progress in legacy modernisation is difficult to see if you are only looking at the end state. Institutions that track leading indicators, the proportion of transactions running through the new system, the reduction in manual workarounds, the decrease in incident volume related to the legacy stack, are better placed to demonstrate value early and maintain organisational confidence in the programme when it inevitably becomes difficult.

The honest conclusion

Legacy systems in government are a genuine problem. The cost of maintaining them diverts resource from building new capability. The brittleness of ageing architectures creates risk. The difficulty of integrating modern tools with decades-old infrastructure slows down digital services that citizens increasingly expect to work seamlessly.

But the solution is not, in most cases, a large replacement programme. It is a sustained commitment to incremental modernisation, led by people who understand the architecture deeply, governed by people who are comfortable with complexity, and executed in small enough steps that the organisation can learn and adjust as it goes.

We’ve seen this play out in financial services, and the lessons are directly applicable to the public sector.

The technology to modernise legacy government systems exists. The architectural patterns are well understood. What is needed is the organisational will to make decisions incrementally rather than waiting for a programme large enough to justify a business case. That is a culture change, not a technology one.

If you are working through a legacy modernisation challenge and want a technical perspective on where to start, we are happy to have that conversation. Reach Mike and the Waracle team at waracle.com/contact, or read more about our work in regulated sectors at waracle.com/industries/public-sector/.