The cost of doing nothing: Why maintaining legacy systems can be more expensive than replacing them

There’s a quiet assumption that sits behind many decisions in public sector digital delivery: leave it as it is, because changing it feels risky. Legacy systems continue running, often long past their intended lifespan, because they are seen as stable, known, and “good enough.”

I’ve worked on multiple services where that assumption turned out to be the most expensive decision in the room.

Not because the systems failed dramatically, but because they didn’t. They limped along. They absorbed time, constrained change, and quietly increased the cost of delivery in ways that were rarely measured properly. Teams adapted around them. Workarounds became normal. Risk was accepted rather than addressed.

The real cost wasn’t the system itself. It was everything that formed around it.

What follows is a breakdown of those hidden costs, and how I’ve approached building a credible case for change within the constraints of public sector delivery.

The Illusion of Stability

Legacy systems often survive because they appear stable. They process transactions, store data, and support core services. On the surface, they work.

But stability in this context is often misunderstood.

In practice, what I’ve seen is a form of fragile stability. The system works because people have learned how to work around it. Knowledge is concentrated in a small number of individuals. Documentation is incomplete or outdated. Changes are avoided because the impact is unpredictable.

I’ve been in delivery teams where a single developer or support engineer became the de facto safety net for an entire service. Not because they designed it that way, but because over time they became the only person who truly understood how the system behaved.

That creates a hidden operational risk. If that person leaves, the service doesn’t just lose capacity — it loses understanding.

From a leadership perspective, this risk rarely appears in business cases or reporting. It’s not captured in financial terms, so it’s easy to ignore. But it directly affects resilience, continuity, and the ability to respond to change.

The system may be stable today, but it’s increasingly brittle over time.

“Before this work, we had a shared understanding that our legacy system was ‘old but stable.’ What your team helped us see was that it wasn’t stable at all — it was being actively held together by people, process, and a growing number of workarounds. The service map you developed made that visible in a way we’d never properly articulated. It shifted the conversation at senior level from ‘why change?’ to ‘why are we accepting this level of risk and inefficiency?’ That clarity was critical in securing alignment and moving forward with confidence.”

Director of Digital Delivery, Central Government Department

The Compounding Cost of Workarounds

Where legacy systems fall short, teams compensate.

Manual processes are introduced. Data is copied between systems. Spreadsheets are used to bridge gaps. Additional checks and approvals are layered in to reduce risk. Over time, these workarounds become embedded in the service.

Individually, each workaround seems reasonable. Collectively, they create significant cost.

I’ve seen services where operational teams were spending hours each day reconciling data that should have flowed automatically. That time wasn’t accounted for as a system cost — it sat within staffing budgets. But it existed purely because the system couldn’t support the service properly.

This is where the cost of doing nothing starts to compound.

Every workaround introduces friction. Every manual step increases the chance of error. Every additional process slows down delivery. And because these are distributed across teams, the true cost is rarely visible in one place.

From a business case perspective, this is one of the most important areas to surface.

You’re not just replacing a system. You’re removing the need for the ecosystem of workarounds that has grown around it.

“What stood out for me was how you translated what we had always considered ‘operational overhead’ into something tangible and measurable. We knew teams were spending time on manual interventions, but we had never connected that effort back to the system itself. By grounding the analysis in real service behaviour — not just technical critique — you gave us a business case that resonated beyond IT. It became a service problem, a cost problem, and ultimately a leadership decision.”

Head of Service Transformation, Arm’s-Length Body

Constraint as a Hidden Delivery Cost

One of the most overlooked impacts of legacy systems is how they constrain delivery.

When a system is difficult to change, it shapes the decisions teams make. Features are deprioritised not because they lack value, but because they are too complex to implement. Policy intent is compromised because the system cannot support it. User needs are partially met rather than fully addressed.

I’ve worked on services where the design solution was driven more by system limitation than by user need. The team knew what “good” looked like, but the cost and risk of changing the underlying system made it unviable within the constraints of the programme.

That has a direct impact on service quality.

It also affects pace. Delivery slows down because every change requires careful navigation of legacy constraints. Testing becomes more complex. Releases become riskier. Teams spend more time managing the system than improving the service.

From the outside, this can look like a delivery problem. In reality, it’s often a system constraint problem.

And over time, that constraint becomes expensive.

The Misleading Simplicity of “Cheaper to Maintain”

A common argument for keeping legacy systems is cost. Replacement is seen as expensive, while maintenance is perceived as the cheaper option.

In isolation, that can appear true. But it rarely holds when you look at the full picture.

Maintenance costs are often fragmented across multiple budgets. Support contracts, specialist resources, infrastructure, and operational overhead are all treated separately. Add to that the cost of workarounds, the impact on delivery speed, and the risk exposure, and the picture changes significantly.

I’ve been involved in shaping business cases where the initial assumption was that replacement would be too costly. But once we mapped the full cost of maintaining the current state — including the indirect costs — the gap narrowed quickly.

In some cases, it disappeared entirely.

The challenge is that these costs are not always easy to quantify. They require a different approach to analysis.

This is where the role of the business analyst or service designer becomes critical. It’s not just about documenting the current system. It’s about understanding how the system affects the entire service, and translating that into a form that decision-makers can act on.

“The biggest shift was moving away from seeing replacement as a technology programme and towards understanding it as a service improvement. Your approach challenged us to focus on user outcomes and delivery constraints rather than the system in isolation. That reframing changed how we engaged with both policy and operations. It gave us a narrative we could stand behind — not just that the system needed to change, but that the service deserved to be better.”

Programme Director, National Public Service Organisation

Making the Case for Change

Building a case for replacing a legacy system is rarely about making a single compelling argument. It’s about connecting multiple strands of evidence into a coherent narrative.

In my experience, the most effective approach starts with the service, not the system.

Instead of asking “what’s wrong with the system?”, I focus on “where is the service struggling?” That shifts the conversation from technical detail to user impact and operational reality.

From there, the work becomes about making the hidden visible.

I’ve approached this by mapping the end-to-end service and identifying where the system introduces friction. That includes manual steps, delays, error points, and dependencies. When you visualise this clearly, it becomes much easier for stakeholders to see the cost of the current state.

Quantifying that cost is the next step, but it doesn’t need to be perfect. Directional estimates, grounded in real operational data, are often enough to change the conversation. For example, calculating the time spent on manual reconciliation and translating that into cost can be surprisingly powerful.

Risk also needs to be brought into the picture. Not in abstract terms, but in concrete scenarios. What happens if a key individual leaves? What is the impact of a system failure? How quickly can the service recover?

Finally, it’s important to frame replacement not as a technical upgrade, but as an opportunity to improve the service.

This is where aligning to user needs becomes critical. Replacement should enable better outcomes — faster processing, reduced errors, improved accessibility, or greater flexibility to respond to policy change.

When the case is framed this way, it moves beyond cost and into value.

Final Thoughts

Legacy systems don’t usually fail all at once. They erode value gradually.

They increase operational cost in ways that are hard to see. They constrain delivery in ways that are hard to challenge. They introduce risk that becomes normalised over time.

The cost of doing nothing is rarely captured in a single figure, but it is felt across every part of the service.

From a practitioner perspective, the role isn’t to push for change for its own sake. It’s to make the reality of the current state visible, and to connect that reality to outcomes that matter — for users, for teams, and for the organisation.

Because once you can see the true cost of maintaining the status quo, the question shifts.

It’s no longer “can we afford to replace this system?”

It becomes: how long can we afford not to?