What Is a Legacy System? Refactor, Rebuild or Replace

A legacy system is software or hardware that your business still depends on but can no longer support, secure, change or connect to other tools at a reasonable cost. Age alone does not make it legacy. Replacing legacy systems is worth it when the yearly cost of keeping them is higher than the cost of a better fix. That cost includes fees, workarounds and risk, and the fix is often smaller than a full rebuild.

This article gives the legacy system meaning in plain terms, with warning signs and examples from small and mid-sized businesses. It sets out your options (rehost, refactor, staged rebuild or replace), how to decide between refactoring and rewriting, and how to plan a data migration. The cautious first step we recommend is a fixed-price assessment. Our rebuild discovery is £4,000 for one system, and our modernisation assessment is £5,000 for a whole estate.

Key takeaways

• A legacy system is one you still rely on but can no longer support, secure, change or connect economically. GOV.UK’s definition turns on the burden or risk the system creates rather than its age.
• Replacing a legacy system is worth it when the yearly cost of keeping it exceeds the cost of the fix. Add up the real numbers before you decide.
• You have five options: leave it, rehost it, refactor it, rebuild it in stages or replace it with packaged software. A full rewrite from scratch is the riskiest.
• A data migration needs a backup you have proved you can restore, a clean-up, trial runs and a way back.
• Our fixed-price starting points are a £4,000 rebuild discovery for one system and a £5,000 modernisation assessment for an estate.

What is a legacy system?

A legacy system is a system that has outlived the support, skills or design it was built around while the business still relies on it. The term covers custom software, packaged software, databases, servers and the hardware beneath them. “Legacy software” and “legacy application” describe the same problem at the level of a single program.

The UK government offers a usable test. Its definition of legacy IT, updated in August 2026, covers “systems whose continued use creates a persistent, unacceptable burden or risk and can no longer be supported or secured effectively or economically” (GOV.UK, 2026). It was written for the public sector, but the test transfers to any business.

The same page lists the criteria. They include systems that are out of support, a lack of required skills and knowledge, an inability to meet user or business needs, and reliance on a legacy dependency.

So the key characteristic of a legacy system is the burden it creates, and age is only one cause. A ten-year-old system that is supported, documented and easy to change is fine. A three-year-old one built by a contractor who has since left can already be a liability.

Is replacing a legacy system worth it?

Replacing a legacy system is worth it when keeping it costs more each year than the fix would, and when the fix is sized to the problem. It is not worth it when the system works, is supported and merely looks dated. We would tell you to keep a system that earns its place, just as we would tell you to buy packaged software when your process is standard.

The scale of the problem is documented. The UK government’s State of Digital Government review estimated that legacy technology made up 28% of systems in central government departments in 2024, up from 26% in 2023. It also said that maintaining legacy systems often costs 3 to 4 times as much as modern alternatives (GOV.UK, 2025).

Those are figures for very large public-sector estates. Treat them as a direction of travel and not as a benchmark for your firm. Your own sums matter more. Add up four numbers for the last 12 months:

• Fees for licences, hosting and support.
• Developer or contractor time spent on fixes.
• Staff hours lost to workarounds, such as re-keying data between systems.
• The cost of any outage or incident.

Then list what the system stops you doing, such as launching a product, connecting a new tool or using your data with AI. That last item is the hardest to price and is often the largest.

Here is an illustration with invented inputs, so replace them with your own. Fees of £1,200 a month plus 25 hours a month of workarounds at £30 an hour (£750) come to £1,950 a month, or £23,400 a year. If a replacement removed half of that, it would save £11,700 a year. Against a build that starts from £15,000, that pays back in about 15 months on build cost alone, before the new system’s own running costs, which belong in your sum too.

If the sum does not favour a replacement, a cheaper option from the list below usually does.

Warning signs the cost is rising

These signs usually appear before a failure does. Several of them together mean a proper assessment is worth its cost.

• Support has ended. When a vendor stops issuing security updates, every newly found weakness stays open. The NCSC puts it directly: “Weaknesses found in unsupported products will remain unpatched and will be exploitable by relatively low skilled attackers” (NCSC). As a dated example, Microsoft’s lifecycle page lists 14 October 2025 as the end-of-support date for Windows 10 Home and Pro. The NCSC adds that extended support does not guarantee every future vulnerability will be fixed, so it should not be seen as a long-term alternative to migrating to a supported operating system.
• One person holds the knowledge. GOV.UK lists a lack of required skills and knowledge as a criterion for legacy IT. In a small firm that often means a single developer or contractor, no documentation and no easy way to hire someone who knows the stack.
• Small changes take weeks. When adding a field or a report means touching many parts of the system, every change risks breaking something else, and the backlog only grows.
• It does not connect to anything. If data moves between your systems by export, re-keying or email, your people are the integration. Our API integration guide covers what a proper connection looks like. Data locked in a system with no clean way out is also data an AI tool cannot use.
• A spreadsheet runs a core process. A workbook that one person maintains and everyone depends on is a legacy system with a friendly face. Our guide to moving from Excel to a web app covers when to replace one.

Legacy system examples

Legacy system examples are easiest to spot by symptom. These are common patterns in small and mid-sized businesses, with the usual first move for each.

Example	Why it hurts	Usual first move
Operating system or database past end of support	No security updates	Upgrade or replatform
Custom software a former contractor wrote	Nobody knows how it works	Assess, then refactor
A spreadsheet or desktop database running a process	One owner, no audit trail	Replace with a purpose-built app
Packaged software on a discontinued version	Cannot update or integrate	Upgrade or replace
An application on ageing servers	Hardware failure risk	Rehost
A core system with one-off integrations	Changes break the links	Refactor the integrations

At the largest scale, the government’s State of Digital Government review points to HMRC’s contracts for maintaining COBOL systems as evidence of those maintenance costs.

Your options: rehost, refactor, rebuild or replace

You have five options, and the cheapest one that solves the problem is usually the right one.

Option	What changes	Best when
Retain	Nothing, apart from monitoring and a review date	It works, is supported and the risk is low
Rehost	Same software, new hosting	Servers or hosting are the weak point
Refactor	Code is restructured, behaviour stays the same	Foundations are sound
Rebuild in stages	New parts replace old ones piece by piece	The system fights every change
Replace	You adopt packaged software	Your process is standard

Rehost moves the software without changing it. AWS Prescriptive Guidance describes rehosting, also called lift and shift, as moving applications “without making any changes to the application”, and describes replatforming as introducing “some level of optimization” (AWS). Rehosting fixes where the software runs. It does not fix how the software is built. If old servers are the problem, a cloud migration through our managed cloud service starts from £5,000.

Refactor improves the code from the inside. Martin Fowler defines refactoring as “a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior” (refactoring.com). Users see no difference on the day, which is why the risk is low.

Rebuild in stages is the strangler fig pattern. New functionality is built alongside the old system, and behaviour moves across in steps. Fowler describes it as moving “bits of behavior from the legacy system into the new code base” until the old system can be retired. He argues that the reduced risk and earlier value outweigh the extra cost of going gradually (martinfowler.com, page dated 22 August 2024). A staged rebuild with us starts from £15,000.

Replace means buying. AWS calls it repurchasing: “You replace your application with a different version or product” (AWS). If your process matches what packaged software already does, buying is usually faster and cheaper than building, and you avoid owning the code. Custom software earns its cost when your process sets you apart or no product fits.

For the replace-and-rebuild end of the range, one client replaced legacy case management, shared inboxes, spreadsheets and supplier portals with one platform. It covers notification, assessment, decision, settlement and repair, with AI assessor-matching, AI document review, multi-scheme support and full audit trails. The claims platform case has the detail.

Refactor vs rewrite: how to decide

Refactor when the foundations are sound, and rewrite only when they are not. A full rewrite from scratch is the riskiest option because it throws away years of accumulated fixes. Joel Spolsky made the case in “Things You Should Never Do, Part I” (6 April 2000). He called Netscape’s decision to rewrite its code from scratch “the single worst strategic mistake that any software company can make” (Joel on Software). His argument is that old code carries tested behaviour and bug fixes that a rewrite must rediscover.

That essay is old and about a product company, but the logic holds for business systems. Rewrites still win sometimes, and these tests help you tell when.

Refactor when:

• The architecture is sound and the pain sits in a few places.
• You can still hire people who know the technology.
• The system has tests, or its behaviour is easy to check by hand.

Rebuild in stages when:

• Every change touches many parts of the system.
• The technology can no longer be supported or secured.
• The data model no longer matches how the business works.
• You cannot reach the source code, or nobody can read it.

Replace when:

• The process is standard and a product already does it well.

These tests are a judgement about your code and your data, so someone has to look at both. That is the job of our rebuild discovery. It reaches a rebuild-vs-refactor decision for one system, and it costs £4,000.

Data migration strategy without the downtime

A data migration strategy is a plan for what moves, in what order, how you check it arrived intact and how you go back if it did not. Data is often the hardest part of a legacy system migration, because years of use leave inconsistent records. Six steps cover most small systems.

1. List what you hold and where. Include data in spreadsheets, shared inboxes and supplier portals as well as the main database.
2. Decide what to move. A migration is a natural time to review retention. The ICO says “You must not keep personal data for longer than you need it” (ICO). It also says to review the data you hold periodically and to erase or anonymise it when you no longer need it. The ICO notes this guidance is under review after the Data (Use and Access) Act, so check the current page. This is not legal advice.
3. Back up first and prove you can restore. The NCSC’s guidance for small organisations says to know how to restore a backup and to check that it contains all your important data (NCSC).
4. Map, clean and trial. Match old fields to new ones, fix duplicates and gaps, then run trial migrations until record counts and key totals reconcile. Clean, consistently structured data is also what later automation needs.
5. Run both systems side by side. Keep the old system live, read-only if possible, while users prove the new one. That is what makes a migration without downtime possible. A single-weekend cutover is cheaper but needs a downtime window the business can accept.
6. Cut over with a way back. Agree a rollback point before the day, and keep the old system available for an agreed period before you retire it.

The first step: a fixed-price audit

Start with the cheapest piece of evidence that settles the decision. Which assessment fits depends on how many systems are involved.

• One system you suspect needs rebuilding. Rebuild discovery is £4,000, fixed, and delivers a rebuild-vs-refactor decision for that system. If you then choose to rebuild, the rebuild starts from £15,000.
• Several systems and no clear order. The modernisation assessment is £5,000 and covers the estate. Phased delivery starts from £15,000, so you fund one move at a time.
• The problem is hosting or hardware. A cloud migration starts from £5,000.

Scope and price are fixed and agreed before work starts. You pay in milestones as each stage is delivered, and all code and IP are yours once the work is delivered and paid for. On a build, you can cancel within the first 21 days and get your money back in full. Ongoing maintenance and support starts from £400 a month.

If you can name the one system that worries you most, begin with rebuild discovery.