How to modernise legacy software while customers keep working

By Devagya Sharma · Published 23 October 2026 · Updated 27 October 2026 · 7 min read

To modernise legacy software while customers keep working, change it one stage at a time. Put a layer between the old system and the new parts, switch each new part on for one team, and prove it gives the same results before anyone else moves. Then turn the old part off on a date you set before the stage began.

This guide covers how to run those stages. It assumes you already know what each part of the product should become, and it links to our guides on that decision and on readiness where they apply.

Key takeaways

• Write the business case around a dated driver, such as a support end date or a regulator's deadline, and around what customers must not notice.
• Agree each part's outcome first: preserve, redesign, replatform or retire. The stages carry those decisions out; they do not make them.
• Put a layer between old and new, hide each new part behind a switch, and keep a way back until the new part has proved itself.
• Prove the new part gives the same results, move whole teams at once, then switch the old part off and remove the scaffolding.

Why modernise legacy software now, and what goes in the business case?

The strongest case for modernising legacy software names a date the business cannot move. Three drivers usually supply one.

• Security. The UK's National Cyber Security Centre says that once a product stops receiving security updates, known flaws become easier for attackers to exploit, and that moving away from obsolete products should be the long-term goal.
• Support end dates. Platforms you build on have published end dates. Microsoft, for example, stopped security fixes for Windows 10 on 14 October 2025. A framework, database or hosting service can reach the same point.
• Regulation. UK financial firms have had to show they can stay within impact tolerances for their important business services since 31 March 2025, under the Financial Conduct Authority's operational resilience rules. An old system that cannot be tested or recovered on demand becomes a compliance problem.

The fourth driver is commercial and harder to date: the product can no longer change at the pace customers and sales need. It is real, and it needs a measure, such as how long a routine change takes to reach customers today.

A business case that survives the first stage states five things. The driver and its date. The parts in scope, and those left alone. What customers must not notice. How long old and new will run side by side, and what that costs. And what the roadmap gives up while the work runs.

What must be agreed before the first stage?

Before the first stage, every part in scope needs an agreed outcome for the people who use it: preserve, redesign, replatform or retire. Our decision framework for legacy software sets out how to assign one per capability and when a rebuild is the right route. The stages below carry those outcomes out, and each outcome sets its own test. A preserved or replatformed part must give the same results; a redesigned part must leave existing users better off.

Two other checks come first. Can the team act on the plan at all? Our 20-question readiness checklist tests that for one capability. And if the team still disputes what a part needs, our worksheet for comparing audit, redesign, modernise or rebuild sets the options side by side for that part.

Where does the old system's real behaviour hide?

The old system's real behaviour sits in four places that code and documents miss. Look in each before you order the stages.

• The people using it. Watch someone do a real task from start to finish. The spreadsheet open beside the system, the note on the monitor and the step everyone does twice are requirements in disguise.
• The support queue. Tickets show which rules confuse people, which exceptions recur and which workarounds support staff hand out.
• Everything that leaves the system. List every export, scheduled email, report, file drop and integration, and who reads each one. These break out of sight.
• The edges of each record. Find where each record comes from, what changes it and what reads it. In our experience, a status that crosses between two systems is where staged work goes wrong.

Then choose the first stage. A good one blocks something the business needs, is used often enough to judge against real work, and has edges you can draw. Where many screens share the same parts, start with those parts, because later stages inherit the decision.

Resist bundling. A framework upgrade, a visual refresh, a change to how the work flows and a design system programme are four pieces of work. Each has its own cost, risk and people who must agree. Priced as one, they tend to succeed or fail together.

How do you modernise legacy software in stages while customers keep working?

Modernising in stages, often called the strangler fig approach, means building new parts beside the old system and moving work across one piece at a time. Each stage runs through the same eight steps.

1. Put a layer between old and new. New parts should not have to speak the old system's data model. Microsoft's architecture guidance describes an anti-corruption layer that translates between the two during a migration in stages, and asks you to decide whether it stays or is retired at the end.
2. Draw the seam where a task begins or ends. Users see the join between old and new, so put it where switching feels natural, such as between finishing an order and tracking it, and never in the middle of a form.
3. Hide the new part behind a switch. A release toggle lets unfinished code ship without anyone seeing it, then turns it on for one team and off again if something breaks. Pete Hodgson's guide to feature toggles warns that each toggle carries a cost and should be removed once it has done its job.
4. Prove sameness. For a preserved or replatformed part, run real cases through old and new and compare totals, dates, exports, permissions and the strange edge cases. Name who signs off that they match.
5. Rehearse the data move. Migrate a copy of real data, check it with the people who use it, and decide in advance what happens to records that do not convert.
6. Run both for a fixed time. Running two systems costs money, so write the exit criteria and the switch-off date into the plan before the stage starts.
7. Move customers in whole teams. People who share procedures and training should switch together, away from their busiest weeks. Our guide on redesigning legacy enterprise software without upsetting users covers choosing cohorts and what to measure as they move.
8. Switch the old part off on purpose. Tell everyone who depends on it, keep the records you must keep, then remove the toggle, the seam and, if it was temporary, the layer.

Throughout, design and engineering need one picture of the product. Engineering decides how a part moves. Someone must also decide what customers see while it moves: which version they get, what the help pages say during the overlap, and how a record that lives in both systems looks in each.

What we saw at the boundary between two systems

In our experience, the seam between two systems is where staged change breaks, because each side was designed for different people. Gold Image Printing's online store fed an internal ERP that staff used to run orders, and both had become outdated. We shadowed the people using the ERP as well as studying the store, then extended one design language across both, working with Gold Image's technical team so the design fitted the systems already running. A change made only on the customer side would have left the staff side behind. The Gold Image Printing case follows the work across both systems.

Questions about legacy software modernisation

What counts as legacy software?

Software becomes legacy when changing it has become slow, risky or expensive, whatever its age. A ten-year-old system that is easy to change is simply mature, and a three-year-old one that nobody dares touch can already be legacy.

How long should old and new run side by side?

Long enough to meet exit criteria agreed before the stage began: results that match, data that has converted, and teams that have moved without a rise in support contacts. Set the switch-off date at the same time, because without one the old part tends to stay.

Who should we hire to modernise a legacy enterprise product?

Hire for the layer that is failing. If people struggle with the workflows and screens, choose a design-led firm that can carry the design into code; if the code, platform or data is the constraint, an engineering firm; if many applications must move at once, a large integrator. Then see what design-led legacy software modernisation involves with us.

What does a first stage of modernisation look like?

Usually one high-use workflow, taken from discovery to customers working in the new version, so you see how change lands before planning the next stage. With us that first stage runs as a pilot at a fixed price agreed before work starts. If your team still disputes which outcome each part needs, a Product Modernisation Assessment recommends a route for each part first.

Can AI tools modernise legacy code for us?

They help with part of it. Tools such as AWS Transform use AI agents to analyse and convert old code, which shortens the reading and translating. They report what the code does; they cannot tell you which of those behaviours customers rely on, or what customers should see while the move happens.