Rebuild or modernise? How to decide what to do with a legacy system

For most legacy systems the right answer is to modernise in stages. You keep the system running, put a clear boundary around it, and replace or upgrade it a piece at a time. A full rebuild is only justified when the existing system can't meet a firm business need and can't be changed safely in parts. If it works, can be supported and isn't holding the business back, simply stabilising it is a sound choice.

What are the options for a legacy system?

Keeping and stabilising a legacy system

Stabilising leaves the system's design alone and reduces the risk of running it. That means getting the code into source control, documenting deployment, adding monitoring and alerting, patching the operating system and dependencies, and putting tests around the parts that change most often.

It suits a system that does its job, rarely changes and still has people who understand it. Think of a stock-control system that has run reliably for years and only needs the odd report tweaked.

Modernising a legacy system in stages

Staged modernisation replaces the system piece by piece while it carries on running, usually with the strangler fig pattern.

The strangler fig pattern puts an interface, such as an API layer or a routing proxy, in front of the old system, then moves functions behind that interface to new code one at a time. Other systems only talk to the interface, so provided each replacement keeps the behaviour they rely on, they can't tell old from new. The old system shrinks until it can be switched off.

Staged modernisation can be far less ambitious. Upgrading the platform counts. So does moving the system from a server under someone's desk to managed hosting, or splitting out the one module that causes most trouble.

Rebuilding a legacy system

A rebuild means writing a new system and switching over when it's ready. You get a fresh design, but all the risk sits in one place and you see no benefit until the switchover. Replacing the system with an off-the-shelf or SaaS product is a rebuild too, with the same data migration and integration risks.

How do you decide whether to rebuild or modernise?

Work through these questions with the technical team and the people who own the business process together.

Does the system still do what the business needs?

If the rules it applies are right and the business hasn't moved on, the value is in that logic. Rebuilding means rediscovering and re-implementing it, often from code nobody has read in years. Where the business has changed so much that the system now models the wrong thing, a rebuild starts to make sense.

Can the system be changed safely?

Ask how long a small change takes from request to release, and how often releases break something. If changes are slow but predictable, find out where the time goes first. It might be code, testing, deployment or approvals. Modernise whichever part is actually holding you up. If every change is a gamble because nobody knows what depends on what, stabilise first and add tests and logging before you try to move anything.

Is the platform still supported?

An unsupported operating system, database or framework is a security and compliance risk, and that usually forces you to do something. It rarely forces a rebuild, though. Upgrading the platform, or moving the code to a supported runtime, is usually a smaller and safer job than starting again.

Who understands the system?

Knowledge that sits with one person is a problem whichever route you take. Write it down first: how the system is deployed, what the scheduled jobs do, which other systems depend on it. Modernising and rebuilding both need that knowledge, so the effort is never wasted.

How tightly is it connected to other systems?

Legacy systems are often wired directly into their neighbours. An order-management system might write straight into the finance database, send the warehouse a file overnight and be read by a reporting tool. A rebuild has to decide, for each of those connections, what to keep, change or retire, and agree that with whoever owns the other system. Putting them behind a defined interface is often the most valuable first step, because every later change gets smaller.

What state is the data in?

Years of data build up quirks. Fields get used for things they were never meant for, duplicates creep in, and some values only make sense if you know the old rules. Data migration is often the hardest part of a rebuild. When the data is messy, staged modernisation lets you clean it and move it in slices you can manage.

Can the business wait?

A rebuild with a single switchover delivers nothing usable until the end, and the old system still has to be maintained alongside it. Staged modernisation delivers improvements as it goes, and you can stop or change direction without writing off the work already done.

What are the warning signs that a legacy system needs attention?

None of these on its own means rebuild, but each one means doing nothing is no longer safe.

• The operating system, database or framework no longer gets security updates.
• Only one person can deploy it, fix it or explain how it works.
• Simple changes take weeks because people are afraid of side effects.
• Outages get fixed by restarting things, not by finding the cause.
• Staff work around it with spreadsheets, copy and paste, or re-keying data between systems.
• New requirements, such as an API for a partner or a new sales channel, can't be met without major surgery.
• Nobody is confident it can be restored from backup, or a restore has never been tested.
• Auditors or customers ask questions about it that you can't answer.

What are the risks of a big-bang rewrite?

A big-bang rewrite builds the whole replacement and then switches over in one go. It promises a clean start, but the risks are easy to underestimate.

The old system keeps changing during the rewrite

The business doesn't stop while the new system is built. Every change to the old one has to be repeated in the new one. The gap can grow faster than the rewrite closes it.

Hidden behaviour gets lost

Legacy systems hold rules that exist only in the code. A discount for one customer group. A rounding step that finance depends on. A field another system reads that nobody remembers. A rewrite built from how people think the system works will miss some, and they turn up after go-live.

Value arrives late, if at all

Until switchover the business pays for two systems and gets nothing from the new one. If priorities shift or funding is cut halfway through, there may be nothing usable to show.

Switchover is all or nothing

One cutover for every user, integration and record puts the whole risk into a single weekend. If it goes wrong, rolling back may mean losing transactions already entered in the new system.

How do you reduce the risk if you do rebuild?

Sometimes a rebuild is the right call: the business needs a fundamentally different system and the existing one can't be changed safely in parts. If that's you:

• Document what the existing system does first, including its integrations, scheduled jobs and reports.
• Build behind an interface, so users or functions can move across gradually rather than all at once.
• Run old and new side by side and compare outputs before switching.
• Rehearse the data migration several times on real copies of the data.
• Freeze changes to the old system, or control them tightly, while the new one catches up.

Should you keep, modernise or rebuild a legacy system?

• Keep and stabilise it if it's correct, runs on a supported platform (or can be moved to one) and rarely needs to change.
• Modernise it in stages if it holds valuable logic but is slow or risky to change, sits on ageing technology, or is tangled up with other systems.
• Rebuild it only if it models the wrong business, the technology can't be upgraded or replaced in parts, and the business can carry both the wait and the risk.

Whatever you decide, start the same way: find out what the system does and who and what depends on it, then make it safe to change.

Getting help

If you are weighing up what to do with a legacy system, our legacy modernisation page explains how we approach it. Email [email protected] with your brief.