Rebuild, replatform or leave it alone: a legacy software decision guide for UK and Irish businesses
Most established businesses have one. It was built years ago, it runs something important, and it still works. Mostly. The person who wrote it has moved on, nobody wants to change it, and every request starts with "we will need to be careful".
The instinct is either to leave it alone or to replace it completely. Both can be right. Both can also be expensive mistakes. The honest answer is that there are several options between those two extremes, and the right one depends on the risk the system carries today and what you need it to do next.
This guide is for business owners and operations leaders in the UK and Ireland who need to make that call.
Signs your legacy software has become a risk
Age alone is not the problem. Plenty of old software is stable and fit for purpose. Watch for these signs instead:
Only one person understands it, and they are overstretched, near retirement or no longer with you.
It runs on unsupported technology, such as an old version of Windows Server, PHP or .NET that no longer receives security updates.
Small changes take weeks and routinely break something else.
Staff work around it with spreadsheets, re-keying and manual checks.
It cannot connect to newer tools, which blocks automation, reporting or AI.
Audits or insurance questionnaires make you nervous, because you cannot say with confidence how it is secured.
You are not alone. Research cited by Made Smarter found 74% of manufacturing and engineering firms still rely on old systems or spreadsheets for day-to-day work.
Your five options
There are five realistic routes, and they are not mutually exclusive. They differ less in headline price than in how much disruption, time and risk you take on.
1. Leave it alone
Keep running it, with monitoring, a named owner and a contingency plan. The lowest effort today, but the risk grows every year. Best when it is stable, secure and not blocking the business.
2. Replatform
Move it onto supported, modern hosting with minimal code change. Usually weeks to a few months, with little change for users. Best when the main risk is the environment it runs on.
3. Refactor
Improve the code in stages: upgrade frameworks, add tests, untangle modules. Ongoing and incremental, and the system stays live throughout. Best when the core logic is sound but hard to change.
4. Rebuild
Rewrite it on a modern foundation, often module by module. The largest investment, taking months, with a careful cutover. Best when the system is critical, specific to you and past saving.
5. Replace
Swap it for an off-the-shelf product. Moderate build effort, plus licences and process change for your staff. Best when your process is standard and a good product exists.
Whichever route you take, data migration and integrations with other systems are where plans most often go wrong. Budget time for both.
The most successful pattern is often sequential. Replatform first to remove the immediate risk, then refactor or rebuild piece by piece from a position of safety, rather than betting everything on a single big switchover.
What has changed in 2026
Two shifts make this a good year to revisit the decision.
The compliance bar has moved. Since 27 April 2026, a Cyber Essentials assessment fails automatically if multi-factor authentication is available on an in-scope cloud service but not switched on (NCSC). Older systems that cannot support modern authentication or clear data controls are becoming harder to certify, insure and defend to customers.
AI has changed the economics of rescue. Tools that read, explain and help refactor old code mean a codebase that was too tangled to touch a few years ago may now be worth saving. That lowers the cost of understanding what you have, which is often the most expensive and risky part of any modernisation.
AI is not a magic wand. It speeds up the work, but it still needs experienced engineers to judge what to keep, what to change and how to prove the result is safe. In a regulated or operationally critical system, that judgement is the job.
A simple way to decide
Work through these four questions in order. The first "yes" usually points to your starting route.
Is it exposed to a security or compliance risk right now? If yes, deal with that first. Usually that means replatforming or targeted fixes, before any bigger decision.
Is your process standard for your industry, and does a good product already do it? If yes, seriously consider replacing it. Bespoke software should earn its place, and good software consultancy should be willing to tell you when it does not.
Is the core logic sound, even if the code is messy? If yes, refactor in stages and keep the value you have already paid for.
Is it critical, specific to how you operate, and blocking what you need to do next? If yes, plan a phased rebuild, starting with the part that causes the most pain.
If the answer to all four is no, leaving it alone may be the right call. Just make it a deliberate decision, with someone named as responsible and a date to review it. If the answers are less clear-cut, talking it through with a software consultant who will be straight with you, including when the answer is to do nothing, is often the quickest way to settle it.
When leaving it alone is the plan
Not every legacy system should be modernised. One long-standing client, a not-for-profit organisation in Northern Ireland, came to us with a platform that had served them well but was reaching the end of its useful life as their services changed.
A rebuild would have meant investing heavily in software with a limited future. Instead, we agreed a planned end-of-life: keep the platform secure and supported while it is still needed, then wind down its cloud infrastructure in stages to a fixed date, with data handled properly along the way.
The result is a decision rather than a drift. The client knows what it will cost, when it ends and who is responsible until then. Sometimes the most valuable thing a software partner can tell you is that you do not need to build anything at all.
Start with an assessment, not a rebuild
The most expensive modernisation mistakes happen when the route is chosen before anyone has looked properly at what is there. A short, fixed-scope technical assessment should tell you:
what the system actually does, including the undocumented parts
where the security and compliance risks sit, ranked by severity
which option fits, with a costed, phased plan
what you can safely leave alone
At Scaffold, this is where our software rescue work begins. Since 2008 we have built and inherited critical systems for organisations across the UK and Ireland, from manufacturers and laboratories to public bodies and legal services. We hold ISO 27001:2022 certification, and whatever we build or rescue, you own. Your code. Your IP. Always.
If you have a system everyone is afraid to touch, start with a technical audit. We will tell you honestly whether it needs rescuing, rebuilding or simply looking after.
Frequently asked questions
What is legacy software modernisation?
It is the process of updating ageing software so it is secure, supportable and able to meet current business needs. That can mean moving it to new hosting, improving its code, rebuilding it or replacing it.
How much does legacy software modernisation cost?
It depends far more on the route than on the size of the system. Replatforming and staged refactoring are usually the lightest options, while a full rebuild is the largest investment. A short technical assessment is the quickest way to get a costed plan for your system rather than a market average.
Should I rebuild or replace my legacy system?
Replace it if your process is standard and a good product exists. Rebuild it if the system is critical, specific to how you operate, and gives you an advantage off-the-shelf software cannot.
Can AI help modernise legacy software?
Yes. AI tools make it faster and cheaper to understand and refactor old code. They still need experienced engineers to guide them and verify the results, especially in regulated environments.
