Menu

Strategy

Legacy systems are not the problem, how you work around them is

Legacy technology creates constraints, but the deeper complexity usually comes from the layers of workaround, duplication, and process that have grown around it over time.

Why replacing old systems rarely solves the real issue on its own, and why the more important work is understanding the operating model that has evolved to compensate for them.

24 June 20234 min read

In short

Why replacing old systems rarely solves the real issue on its own, and why the more important work is understanding the operating model that has evolved to compensate for them.

Why legacy systems get blamed so easily

Older do come with limitations. They're harder to change, often poorly documented, and rarely designed for how products operate today. But over time, teams workarounds. are adjusted to compensate for gaps. Additional steps are introduced to handle edge cases. Different departments solve the same problem in slightly different ways because there's no single path that works for everyone. Individually, those decisions make sense. Collectively, they create complexity. What starts as a workaround becomes the way things are done.

The also makes a convenient subject because it cannot object. Naming a as the problem implicates the team that runs it. Naming the implicates nobody in the room, which is part of why the diagnosis lands so easily and goes unchallenged.

What creates the deepest friction is rarely the legacy system itself. It is the way the organisation has learned to work around it.

Why replacing the platform often changes less than expected

By the time is being considered, those workarounds are deeply embedded. They're no longer seen as temporary fixes, but as part of the itself. People rely on them. are built around them. Entire workflows exist to compensate for limitations that were never properly addressed.

Replacing the doesn't remove that. What often happens is that a new is introduced with the expectation that it will simplify everything. But the same are carried over. The same workarounds are rebuilt. The same inconsistencies are preserved, just implemented in a different way. The technology changes. The behaviour doesn't.

Requirements gathering is where it gets locked in. Asked what the new must do, people describe what the current one does, including the workarounds, because that is what the job now consists of. The specification captures the compensations faithfully and carries them across intact.

Key takeaway

The real complexity usually comes from the operating model that has evolved around the system, not from the system in isolation.

What changes when you look at the operating model first

What shifts this is not replacing the first. It's understanding everything that has formed around it. That means looking at how work actually flows through the organisation: where decisions are made, where duplication exists, where people are compensating for gaps that shouldn't be there. It means identifying the workarounds, not just accepting them as part of the .

Once those are visible, they can be challenged. Some can be removed entirely. Others can be simplified. In many cases, what looks like a limitation is actually a that has evolved unnecessarily over time. Not everything needs to be carried forward.

The workarounds are rarely written down anywhere, which is what makes them hard to find. They live in the spreadsheet somebody maintains privately, the message sent to a colleague to unblock a case, the field being used for something other than its label. Those are the things worth asking about directly.

Why the system should enable the model, not define it

Instead of asking what the new needs to do, the focus should shift to how the organisation needs to operate. What should the look like if it was designed properly? Where can steps be removed? Where can ownership be clarified? Where can be introduced? Only then does the system come into play, as an enabler, not a constraint.

When this work is done upfront, often become more manageable than expected. In some cases, they can even support improvements without immediate replacement, simply because the way they're being used has changed. Legacy do have limitations. But they're rarely the reason things aren't working. It's the layers of , workarounds, and decisions that have built up over time that create the real friction. Until those are addressed, replacing the system won't solve the problem. It will just move it somewhere else.

This also changes what a business case can honestly claim. Savings attributed to a replacement are usually savings from removing , and process can often be removed without replacing anything. Separating the two makes the case weaker on paper and considerably more likely to be realised.

Written by Andy Scott

Strategic design, UX and digital transformation thinking from real projects.

LET'S WORK TOGETHER

Ready to improve your product?

UX, research and product leadership for teams tackling complex digital services.

Previous feedback

I had a fantastic experience working with Andy. One of his most impressive achievements during our time at NHS HEE was masterminding a deeply complex information architecture for a new platform that brought together a large number of legacy websites.

Will Parkhouse

Senior Content Designer