Legacy Software Modernisation: A Step-by-Step Plan for UK Businesses

Legacy software modernisation goes best as a series of small, reversible moves. You map what the system really does and choose an approach for each part. You record its behaviour in tests, replace it slice by slice while the old system keeps running, and measure the result against a baseline set on day one. A full rewrite from scratch is the riskiest route and rarely where we start.

This is the how-to. Our guide to legacy systems covers the definition, the warning signs and the refactor-or-rebuild decision, so we do not repeat them here. Below are the steps in order, how to pick an approach for each part, where AI tools help, what it costs and how to know it worked. Our legacy modernisation assessment is £5,000 for a whole estate, and our rebuild discovery is £4,000 for one system. Both are fixed price.

Key takeaways

• Modernise in slices, with a way back. Replacing a system gradually keeps the business running and keeps the risk in small pieces.
• Choose an approach for each component. Most estates need a mix of leaving alone, wrapping in an API, rehosting, refactoring and replacing.
• Record what the old system does before you change it. Its behaviour, including rules nobody wrote down, is your specification.
• AI tools help with reading old code and repetitive changes. They cannot tell you which undocumented rules matter.
• Our fixed-price starting points are a £4,000 assessment of one system or a £5,000 assessment of an estate, then delivery from £15,000.

What does legacy software modernisation involve?

Six steps, in order, each ending with something you can check before you pay for the next.

Step	What you do	You end with
1. Map	Inventory systems, data, rules, links	A baseline and a ranked list
2. Choose	Pick an approach per component	A decision for each part
3. Test	Record what the old system does	Checks the new code must pass
4. Replace	Swap in one slice at a time	Live slices, old system still running
5. Migrate	Move the data and cut over	A tested way back
6. Measure	Compare with the baseline	Proof it worked

Steps 3 to 5 repeat for each slice. The first two steps make a fixed-price piece of work on their own, and what they produce is yours to give to any team.

Step 1: Map what the system does and what depends on it

Start with a written inventory, because you cannot sequence work on a system you have not mapped. For each system, record five things.

• What it does. The functions, by user and by process. Watch people use it as well as reading the code.
• Its data. Where it lives, who owns it and how clean it is.
• Its connections. Every system it talks to, including exports, emails and scheduled jobs.
• Its support status. The NCSC’s Cyber Essentials requirements (v3.3, April 2026) say software on in-scope devices must be licensed and supported. It must be removed when it becomes unsupported, or moved out of scope into a defined sub-set that prevents all traffic to or from the internet. If Cyber Essentials applies to you, an unsupported component is a compliance problem as well as a security one.
• Who knows it. If one person holds the knowledge, fix that now rather than at the end.

Hidden business rules cause the expensive surprises. A rounding rule, an approval that only one screen enforces or a report filter that quietly drops duplicates can each matter to someone. They live in the code, database constraints, support tickets, spreadsheets kept beside the system and the heads of people who use workarounds. Our rebuild discovery works this way. We read the running system and its code to recover what it does today, including the undocumented behaviour the business depends on.

Then map which system talks to which, so you do not change one in a way that breaks the system feeding it. Finish by writing down a baseline: what the system costs to run, how often it fails, how many hours go on workarounds and how long a small change takes. Step 6 compares against it.

Our modernisation assessment does this step across an estate. It inventories and risk-rates every system in scope, shows what each costs and returns today, and delivers a roadmap sequenced by payback. Buying or investing in a company with legacy code is a different job, covered by technical due diligence.

Step 2: Choose an approach for each part

Decide for each component, because one estate usually needs several approaches at once. Start each decision from what is wrong with that component today.

Approach	What it means	When it fits
Leave it	Change nothing, monitor it	Stable, supported, rarely changed
Wrap in an API	Keep the code, add a clean front door	Others need its data or functions
Rehost	Move to new hosting unchanged	The hosting is ageing
Replatform	Move with small changes	Upkeep is the main cost
Refactor	Restructure code, same behaviour	Sound design, untidy code
Strangler fig	Replace slice by slice	It must stay live throughout
Full rewrite	Build new, switch once	Small system, simple rules
Replace with a product	Buy a package or subscription	A package already does the job

Wrapping is often the cheapest useful first move. Other systems can read and write through an interface you control, and you gain a point where a later replacement can plug in. Our API integration guide covers what a proper connection involves.

Rehosting and replatforming change where the software runs and leave how it is built largely alone. Our cloud migration for SMEs guide covers both, and a migration through our managed cloud service starts from £5,000.

Keeping systems and connecting them is sometimes the whole answer. For an international events group running 20+ exhibitions, we connected Pipedrive, SmartDocs and Xero without replacing any of them. Signature detection updates the CRM, and Xero raises the invoice on signature. Around 500 sales invoices a month no longer get typed by hand. The events group case was delivered in three phases.

Consolidating helps when several tools share one job. On our claims platform work, one client replaced legacy case management, shared inboxes, spreadsheets and supplier portals with one platform covering notification, assessment, decision, settlement and repair.

Replacing with a product is the right answer more often than builders admit, whenever the process is standard. We will say so before quoting a build. The tests for refactoring against rewriting are in our legacy systems guide, which also explains why a full rewrite from scratch is the riskiest option.

Step 3: Put tests around the old system first

Before you change a component, record what it does today. The old system’s behaviour is your specification, including the parts nobody can explain.

Take real inputs, such as a month of orders, run them through the old system and store the outputs as automated checks. Martin Fowler describes Michael Feathers’s book Working Effectively with Legacy Code as focused mainly on getting a legacy system under test. Fowler notes that Feathers coined the term seam in that book, for a place where you can change behaviour without editing in that place (Martin Fowler, 2024).

Later, run the old and new code on the same inputs and compare. Each difference is a bug in the new code or a rule you did not know about, and sometimes a bug the old system always had. Both are cheap to find now and costly after launch. If a difference is a deliberate change, record it in writing and have a business owner sign it off.

If a system offers no seams and no source code, compare at the edges instead: reports, exports and any interface responses.

Where AI coding tools help, and where they do not

AI tools are useful for reading unfamiliar code, summarising modules, drafting first-pass tests and making repetitive changes. Google engineers published an experience report on using large language models for the company’s internal code migrations. The authors say they see evidence that the tools can reduce the time migrations take significantly (arXiv, 2025). That is Google’s scale, so test the idea on your own code.

They do not know intent. A model can describe what code does and still miss why, and the rules that matter most are often in people’s heads or in other systems. Treat its output like a new starter’s work. Review it and run it against the recorded tests. Before you point any tool at a proprietary codebase, check what happens to your code and data.

Step 4: Replace in slices while the business keeps running

The strangler fig approach replaces a system a slice at a time, behind a front door, so users keep working throughout. Martin Fowler wrote that “The alternative that my colleagues and I prefer, is to do a gradual process of modernization” (Martin Fowler, 2024).

Microsoft’s architecture guidance describes the mechanics. A façade (proxy) intercepts requests going to the legacy back end and routes them either to the old application or to the new services. Users keep working through the same interface and need not know that a migration is under way (Microsoft Learn, 2026).

Pick the first slice carefully. Choose something small, valuable and loosely tied to the rest. Fowler notes that “Since these components are small, there isn’t so much risk involved when we introduce the new software.” Microsoft adds that the approach lets you do high-return replacements before low-return ones. That matches how we sequence a roadmap, with payback and risk deciding the order.

Use a switch for each slice. Pete Hodgson defines feature toggling as “a set of patterns which can help a team to deliver new functionality to users rapidly but safely” (martinfowler.com, 2017). For a slice, a flag lets you send a few users to the new code, then more, and send them back if something looks wrong.

Plan for the two systems to coexist. Microsoft says to decide how to handle services and data stores that both the new and the legacy system might use. It also recommends an anti-corruption layer, an adapter that translates between the two so the new design keeps its own conventions. On our builds, the old system keeps running in parallel until the new one is proven.

Know when it does not fit. Microsoft lists cases where the pattern might not suit. Requests to the back end may be impossible to intercept. You may be unable to change the source code or any other integration point. Or the system may be small enough to replace whole, or need switching off quickly. In those cases a wrapper, a rehost, a product or a small rewrite is the better choice.

Who does the work

Keep someone from the business who owns the process on the project every week. Engineers can rebuild a rule, but only the business can say which rules to keep. Pair anyone who holds unique knowledge with a second person, and write down what they know. If you lack engineers, our guide to staff augmentation explains how borrowing them works. All code and IP are yours once delivered and paid for, and ongoing maintenance and support starts from £400 a month.

Step 5: Move the data and cut over with a way back

Data is often the hardest part. Our legacy systems guide sets out a six-step data migration plan, including backups, retention and trial runs. Slice-by-slice work adds one rule: decide which system owns each piece of data at each stage.

Microsoft’s database example shows the sequence. The new service first reads and writes the old database for its own area. Next, an isolated new database is loaded from the old one and kept in sync while the legacy system carries on working. Microsoft says to validate consistency between both databases before cutover. Only then does the new database become the system of record.

Microsoft notes you can roll back while the old tables and synchronisation still exist, and that rolling back after they are removed takes significant effort and risk. Its advice is to “Treat the removal of legacy objects as a deliberate final step for each domain” (Microsoft Learn, 2026).

For the cutover itself:

1. Name who can call a rollback for each slice, and what would trigger it.
2. Keep the legacy tables and synchronisation in place until that slice has run cleanly.
3. Wait for a full business cycle, such as a month end, before retiring it.
4. Then switch off the old licences, hosting and access, so the saving in step 6 is real.

What it costs, how long it takes and how to measure it

Cost depends on how many systems are in scope, how well they are documented, how much data moves and how many integrations exist. We fix scope and price before work starts. These are our published prices.

Stage	What it covers	Price
Modernisation assessment	Estate reviewed, roadmap delivered	£5,000
Rebuild discovery	One system, assessed	£4,000
Phased delivery	Roadmap to live systems	From £15,000
The rebuild	Spec to live system	From £15,000
Cloud migration	One-off project	From £5,000

You pay in milestones as each stage is delivered, never a large sum up front. On a build such as phased delivery or the rebuild, you can cancel within the first 21 days and get your money back in full.

We do not give one timeline, because it depends on the estate. Fowler’s point is that “Replacing a serious IT system takes a long time, and the users can’t wait for new features.” Slices answer that. Each one goes live and starts to pay back before the next begins, and you can stop between slices.

How to measure success

Use the baseline from step 1 and compare it on a date you set in advance:

• Business measures. Cost to run, incidents, hours spent on workarounds, and how long a small change takes. A countable task works best, such as the events group’s around 500 sales invoices a month that no longer get typed by hand.
• Delivery measures. DORA’s software delivery metrics include change lead time, change fail rate and failed deployment recovery time (DORA, 2026). They show whether the new system is easier and safer to change. They measure delivery rather than business value, so use them alongside the business measures.
• Support status. The number of components that are unsupported should reach zero.

Your first step

Pick the system that worries you most and have it assessed before you commit to a method. If you can name one system and suspect a rebuild, rebuild discovery is £4,000, fixed. If you have several systems and no clear order, the modernisation assessment is £5,000 and covers the estate. Either way the output is yours to keep, and if the answer is to leave a system alone, we will say so.