Legacy system replacement: migrate without stopping the business

Replace a legacy system in stages, not in one weekend. Put a layer in front of the old system, move one area of the business at a time to the new one, run both side by side until the numbers match, and only then switch the old part off. The business keeps working, and each step can be undone.

What counts as a legacy system?

UK government guidance on its Legacy IT Risk Assessment Framework (GDS and CDDO, as of October 2026) describes legacy IT as outdated and often obsolete systems, software and hardware that have been in use for a considerable period of time. Age alone is not the problem, though. A ten-year-old system that is supported, understood and still fits the business is just a system.

The framework scores likelihood against seven criteria, and four of them translate directly to a small business:

• End of support. The supplier no longer ships fixes, or the platform it runs on is out of support.
• Lost knowledge. The one developer or member of staff who understood it has left, and nobody else dares change it.
• It no longer fits. The business has changed and the system has not, so the gap is filled by spreadsheets and re-keying.
• Known security weaknesses that cannot be patched.

If two or more of those are true of a system your business runs on, it is time to plan its replacement, not just its next repair.

Why do big-bang replacements go wrong?

A big-bang replacement means building the whole new system, then switching everyone over on one date. It looks tidy on a plan. In practice, in our view, it fails for three reasons:

1. The old system does more than anyone wrote down. Years of small fixes, odd reports and workarounds live inside it. They only come to light when they stop happening.
2. Nothing is tested on real work until the switch. Every problem arrives on the same day, while staff are also learning a new tool.
3. There is no easy way back. Once data has been moved and the old system switched off, reversing the decision is slow and expensive.

That does not make big-bang always wrong. Microsoft's guidance (below) says the staged approach may not suit a small system that is simple to replace whole, or a case where the old system must be switched off quickly.

What is the staged approach, and how does it work?

The best-known version is the Strangler Fig pattern. Microsoft's Azure Architecture Center description (updated May 2026) sets it out as incremental migration: replace specific pieces of functionality one at a time, so the new system grows around the old one until the old one can be switched off.

In plain terms, the steps are:

1. Put a layer in front. A facade, often a small routing service or a shared login and menu, sits between your users and both systems. To start with, almost everything still goes to the old system.
2. Move one area at a time. Pick one part of the business, such as quoting, job scheduling or customer records, rebuild it in the new system, and route just that area to it. Users keep working the way they did.
3. Repeat until the old system is empty. Each round shrinks the old system and grows the new one.
4. Switch the old system off, then remove the layer once nothing depends on it.

Microsoft's guidance also notes that each step can be rolled back until the old data is removed, which is the real safety net. It lists when the pattern does not fit, including when requests to the old system cannot be intercepted and when you have no access to its code or any other integration point, such as its database.

Which part should you move first?

Choose something that matters enough to prove the approach, but not the part that would stop the business if it went wrong. Good first candidates tend to be:

• An area people already work around in a spreadsheet, so the new version replaces the workaround as well.
• Something with clear inputs and outputs, so you can compare old and new results line by line.
• A part with a deadline attached, such as a supplier ending support for one module.

Leave invoicing, payroll and anything a regulator sees until the method has worked at least once.

How do you handle the data?

Data is where most of the risk sits. While both systems run, they often need the same records: customers, products, stock. Microsoft's guidance is explicit that both systems must be able to reach shared data at the same time, and its worked example copies one area's data to the new database, keeps the copy in sync, and checks the two match before the new system takes over.

For an SME, that boils down to four rules:

• One owner per record. At any moment, each type of data has one system of record. The other system reads it; it does not edit it. Agreeing who owns what is the core of lightweight data governance.
• Clean before you move. Duplicates and dead records copied across become the new system's problem, so remove them first.
• Reconcile in numbers. Record counts, totals and a sample of individual records, compared between old and new, every time.
• Keep history readable. Decide what old data has to stay available, and for how long, before anything is deleted.

If the old system feeds reports, plan those feeds too. Moving reporting onto a proper data pipeline during the migration means the reports stop depending on which system holds the data this month.

How long should old and new run side by side?

Until the new part has handled real work and the people using it trust the numbers. Our rule of thumb is at least one full business cycle, such as a month-end or a payroll run, before the old part is switched off. Parallel running costs time, because some things are done twice, but it is the cheapest insurance in the whole project.

What if the old system is out of support and you cannot replace it yet?

Then contain it. The NCSC's guidance on obsolete products (reviewed May 2025) says weaknesses in unsupported products remain unpatched and can be exploited by relatively low-skilled attackers, and that stopping using the product is the only fully effective fix. Until then it recommends cutting the routes into it, such as email, web browsing and removable media, treating it as untrusted and separating it from the rest of the network.

That buys time. It is not a plan, which is why GOV.UK's guidance on preventing technical debt and legacy asks every service for a named owner, an asset register entry and money set aside for future upgrades. Those three habits are worth copying in a business of any size, so the new system does not become the next legacy one.

Who should do the work?

Someone who has built and run systems like yours, and who will be honest when a part is better bought than rebuilt. Before committing, it is worth an independent technical due diligence review of the old system so the plan rests on what it actually does, and a clear build vs buy decision for each area you move. Connecting the new system to your CRM, finance or website follows the same patterns as any CRM and ERP integration.

If you are looking at a system the business has outgrown, see how we approach app development and custom web apps, or tell us what you are running today.

Frequently asked questions

What counts as a legacy system?

UK government guidance describes legacy IT as outdated and often obsolete systems, software and hardware that have been in use for a considerable period of time. For an SME the practical test is simpler: it is out of support, nobody can safely change it, or it can no longer do what the business needs.

Should we replace a legacy system all at once or in stages?

For a system the business runs on every day, in stages is usually safer: move one area at a time while the old system keeps running the rest. Replacing everything in one go can make sense when the system is small, the cutover is simple, or the old one has to be switched off quickly.

How long should old and new systems run side by side?

Until the new one has been checked against the old one on real work and the people using it trust the numbers. For most SME systems that means at least one full business cycle, such as a month-end or a payroll run, before the old system is switched off.

Is it safe to keep using a system that is out of support?

It is a risk you manage, not one you remove. The NCSC says weaknesses in unsupported products stay unpatched and that stopping using them is the only fully effective fix. Until you can replace it, cut its routes to the internet and email and keep it away from the rest of the network.

---

Easy Insight is a UK consultancy for AI, web, apps and data — senior specialists only, no juniors.