Legacy system modernisation without the risk

Most businesses have at least one system that's older than anyone would like. It holds years of data and a pile of rules nobody ever wrote down. Changing it is slow, and people are a bit nervous about touching it at all. Legacy system modernisation means bringing that software up to date without breaking the business that relies on it every day.

We wrote this for operations directors, product owners and technical leads who can see an old system holding them back, but can't afford a long outage or a project that fails halfway.

How do you know a legacy system needs attention?

An old system isn't a problem just because it's old. What you want to know is whether it now costs you more, in risk, time or missed chances, than fixing it would. Here are the warning signs we come across most.

• Small changes take weeks. Adding a field to a form or a new report means a long chain of manual steps, and every release feels like a gamble.
• Only one or two people understand it. When they leave or retire, everything they know walks out with them.
• The technology is out of support. Its operating system, database or programming language no longer gets security updates from the maker.
• It won't connect to newer tools. There's no API (an agreed way for two systems to swap data), so staff retype data from one screen into another.
• Workarounds are everywhere. Spreadsheets, shared inboxes and sticky notes cover the jobs the system can't do.
• The same security or audit findings keep coming back. They get flagged every time, but a proper fix would mean changing code nobody dares to touch.

If two or three of these sound familiar, it's time for a proper review. If it's just one, careful legacy application support may be all you need for now.

What are the options for legacy system modernisation?

You rarely pick just one. Most organisations mix them, using a different option for each part of the system. Here are the five main choices, starting with the lightest touch.

Keep and support. Leave the system as it is, but look after it properly. That means security patches, monitoring, bug fixes, written notes on how it works and a second person who understands it. It's the right call for a stable system that does its job and rarely needs changing.

Rehost. Move the system, mostly unchanged, off ageing servers and onto modern hosting such as AWS or Azure. You stop worrying about failing hardware, although the code itself stays the same. Our cloud migration checklist explains how to plan that move.

Refactor. Tidy and improve the existing code without changing what users see. You might upgrade the framework, add automated tests or put an API in front of the database. This works well when the design is basically sound and it's the code that has aged.

Replace piece by piece. Build the new system around the edges of the old one and move features across one at a time. Eventually the old system has nothing left to do and you switch it off. Developers call this the strangler pattern, after the strangler fig, a plant that grows around a host tree and slowly takes its place. Your staff keep working the whole time, and each step is small enough to test and undo.

Full rebuild. Write a new system from scratch and move everyone onto it. That can work for a small system, or when the business process itself is changing completely. For anything large that people rely on every day, it's the riskiest option on this list.

Treat this as a rough guide. Plenty of projects combine options, for example rehosting first and then replacing the busiest parts piece by piece.

Why do big bang rewrites so often fail?

In a big bang rewrite, you build the whole replacement in one go and move everyone onto it on a single day. The appeal is a clean start. In practice it tends to go wrong for the same handful of reasons.

• The old system keeps changing. While the new one is being built, the business still needs fixes and features in the old one, so the thing you're copying keeps moving.
• Users wait a long time for anything. Months go by with nothing to show, and patience or budget often runs out before the finish line.
• Hidden rules get missed. The old system does things nobody remembers asking for. You only find out when the new one goes live and something quietly stops working.
• The switch is all or nothing. If launch day goes badly, there's no easy way back, and every problem hits you at once.

So change in smaller steps you can undo, and make sure each one gives people something useful.

How do you map what the old system really does?

If there's any documentation at all, it's rarely complete. The truth lives in the running code, the data and the heads of the people who use the system every day.

• Watch people work. Sit with the teams who use it and note down every screen, report, export and workaround.
• List every connection. Track down each file transfer, scheduled job, email and integration that moves data in or out, including the one that runs from somebody's desktop.
• Read the code for business rules. Look for the logic that sets prices, discounts, approvals, tax, rounding and cut off times. This is where most surprises hide.
• Study the data. Old databases often use special values, like a date of 1 January 1900 meaning "unknown", and other parts of the system depend on them.
• Note what nobody uses any more. Every feature you can retire is one less thing to rebuild.

The riskiest part of an old system is the rule that works so well that everyone has forgotten it.

What you end up with is a written map of features, rules, data and connections, each marked keep, change or retire. That map becomes your checklist for the rest of the project.

How do you move data safely?

Data is usually the hardest part. It carries years of history and every quirk the old system ever had. Treat moving it as a separate piece of work, and test it well before the day you switch over.

• Look hard at the data first. Count the records, check for duplicates, gaps and strange values, and agree with the business how each problem gets handled.
• Write the move as scripts you can repeat, rather than copying by hand, so you can run it, check it and run it again as often as you need.
• Practise with real volumes. Do full trial runs into a test environment and time them, so you know how long the real move will take.
• Check the numbers match. Compare record counts, totals and a sample of individual records between old and new, and get the business to approve each check.
• Keep a way back. Take a full backup before the move, and keep the old data readable for as long as the business or regulators need it.

How do you run old and new side by side?

A staged approach is safe because, for a while, the old and new systems run together. There are three common ways to do it.

A routing layer. Every request comes in through one front door, which sends each feature to either the old system or the new one. When a feature moves across, you change its route. If something goes wrong, you point it back.

Parallel running. Both systems handle the same work and a script compares the results. Once they've matched for a period the business is happy with, you switch the new one on for real.

Gradual release. Put a small group on the new version first, perhaps one office or one product line, then widen it bit by bit. Feature flags (settings that turn a feature on or off without a new release) make this easy to control.

Whichever you choose, agree up front who can call a rollback and what would make them do it.

How should you test a modernised system?

You're trying to prove one thing: the new version does everything the old one did, plus the changes you meant to make, and nothing else.

• Record today's behaviour first. Before touching the code, write characterisation tests. These are automated checks that capture what the system does now, right or wrong, so you'll notice if anything shifts.
• Test with real scenarios. Work through the business rules from your map, especially the awkward ones like leap years, refunds and year end.
• Automate the checks. Run them on every change through CI/CD (an automated pipeline that tests and releases every change).
• Test speed and security as well as features.
• Ask real users to try it before each stage goes live. They're the ones who'll spot the missing report nobody else knew existed.

What does a staged roadmap look like?

No two projects are the same, but a safe legacy system modernisation tends to follow a familiar shape. At the end of each stage you have something working, and you decide what comes next.

A staged modernisation roadmap

1. AssessMap the features, rules and data.Stage 1
2. StabilisePatch it, watch it and add tests.Stage 2
3. Open upAdd APIs and a routing layer.Stage 3
4. Most of the workMove in slicesOne feature at a time.Stage 4, repeated
5. RetireSwitch off the old parts.Stage 5

Stage 4 repeats for each feature or module, so users get improvements all through the project instead of waiting until the end.

Stabilise makes the old system safer to live with while the work goes on. Move in slices starts with something useful but low risk, so the team learns how the system behaves before touching its core. Retire switches off whatever is no longer used and archives its data.

How long all this takes depends on how big the system is, what state its data is in and how many other systems it talks to. Replacing a large core system is usually a longer programme, with working releases along the way.

How do you keep the business running during the change?

The project should never be the reason the business grinds to a halt. A few simple habits protect everyday work.

• Plan releases around your calendar, well clear of month end, peak season and audits.
• Tell people what's changing and when, with short guides and a named person to ask.
• Keep supporting the old system until each part is switched off, so urgent fixes still get done.
• Agree your rollback rules before each switch over, not in the middle of one.
• Measure what users care about, like processing time or error counts, so you can show each stage made things better.

How does V6 Cube approach legacy modernisation?

First we listen, then we map. You tell us what the system does and where it's letting you down, and we go through the code, the data and the connections. We're happy to sign a confidentiality agreement before you share any detail. You then get a written recommendation for each part of the system (keep, rehost, refactor, rebuild or replace piece by piece) with a fixed estimate agreed before work begins.

If the system needs looking after before it needs changing, our software maintenance and support service covers security updates, bug fixing and legacy application support. When it's time to rebuild or refactor, our custom software development team builds the replacement in stages, and our cloud migration services take care of the move to modern hosting. You own all the code and designs we produce. Read more about how our software development process runs, or tell us about your system and we'll reply within one business day. Our pages on insurance software and public sector software show how this works with policy and case systems.