Refactor legacy software when the business logic is still right but the code is hard to change. Replace it with an off-the-shelf product when your process is no longer unusual. Rebuild only when the architecture fundamentally no longer fits the business and you can afford months of parallel running. Gradual refactoring with selective rebuilding is usually the lowest-risk route.
"Legacy" does not mean old. It means software that the business depends on but finds hard or risky to change. A five-year-old system can be perfectly healthy, and a two-year-old one can already be legacy if it was rushed. This guide compares the main modernisation options so you can choose with your eyes open. Modernisation decisions sit inside wider software planning, which our guide to building custom software covers in depth.
How do you know your software needs modernising?
You need to modernise when the cost and risk of keeping the system as it is exceed the cost and risk of changing it. In practice, owners notice a cluster of symptoms rather than one clear moment.
Typical triggers:
- the framework, language version or database is out of support and no longer gets security patches;
- simple changes take weeks, and estimates keep growing;
- only one person, often a long-departed contractor, understood how it worked;
- it cannot connect to the tools you now rely on, such as payment gateways, accounting software or a CRM;
- it does not work well on mobile, and your staff or customers now expect it to;
- hosting is fragile, deployments are manual and backups have never been tested.
Most of these symptoms are forms of accumulated technical debt. If you want to put a figure on what that is costing you before deciding, our guide to estimating what technical debt costs your business walks through a simple method.
What are the options, in plain English?
There are five realistic routes, not three. Rebuild, refactor and replace are the famous ones, but two lighter options often solve the problem for less.
- Keep and protect. Leave the core system alone but fix the urgent risks: patch what you can, add backups and monitoring, restrict access. A holding position, not a strategy.
- Wrap it. Put a modern interface or API (a defined way for other software to talk to it) around the old system, so new tools can use its data without touching its insides.
- Refactor. Improve the internal structure of the code step by step without changing what it does, often upgrading the framework along the way.
- Rebuild. Write a new system from scratch, usually on a modern stack, reusing the business rules but not the code.
- Replace. Retire the custom system and move to an off-the-shelf product, configured to your needs.
How do the options compare on cost, risk and time?
Each route trades cost against risk differently. The table summarises the typical pattern; your actual numbers depend on the size of the system.
| Route | Relative cost | Delivery risk | Typical timeline | Best when |
|---|---|---|---|---|
| Keep and protect | Lowest | Low | Days to weeks | You need time to decide, or the system will be retired soon |
| Wrap with an API or new front end | Low to medium | Low to medium | Weeks to a few months | Core logic works, but it must talk to modern tools or users |
| Refactor incrementally | Medium, spread over time | Low to medium | Ongoing, in small releases | Business logic is right; code and stack are the problem |
| Rebuild from scratch | High | High | Often 4–9 months for a mid-size platform | Architecture no longer fits how the business works |
| Replace with off-the-shelf | Licence fees plus migration | Medium | Weeks to months | Your process is now standard and a product fits most needs |
For a sense of scale, a mid-size web platform typically costs in the range of US$50k–150k to build new, as an estimate that varies widely by scope. A rebuild should be budgeted at least like a new build, plus data migration and a period of running both systems.
Why is a full rebuild so risky?
A rebuild is risky because the old system contains years of business rules nobody wrote down. Every special case, discount rule and odd workflow has to be rediscovered and rebuilt, and the business keeps changing while you do it.
The common traps:
- The parity trap. Teams try to copy every feature of the old system, including ones nobody uses, and the project grows endlessly.
- The frozen business. While the rebuild runs, the old system still needs changes, so effort is split.
- Big-bang cut-over. Switching everything over on one day means any missed rule hits all users at once.
- Data surprises. Old databases hold inconsistent, duplicated or half-filled records that break the new system's assumptions.
A rebuild is a business project, not a coding project. It succeeds when someone owns the question "what should this system do now?" rather than "what did the old one do?"
What is the gradual-replacement approach?
The gradual-replacement approach, often called the "strangler fig" pattern, replaces a legacy system piece by piece instead of all at once. The name comes from a vine that slowly grows around a tree until it can stand alone.
How it works:
- Put a routing layer in front of the old system, so requests can go to either the old or new code.
- Pick one well-defined area, such as invoicing or customer accounts, and build it new.
- Route that area's traffic to the new code, while everything else still uses the old system.
- Repeat, area by area, until the old system handles nothing and can be switched off.
This takes discipline, but it means every step delivers value, each risk is small, and you can pause if priorities change. It combines naturally with refactoring: refactor the parts that are nearly right, rebuild the parts that are not.
When does replacing with off-the-shelf software make sense?
Replace when what once made your process special is now standard. Ten years ago a custom booking or CRM system might have been the only option; today mature products may cover most of what you need.
Ask yourself:
- Does an existing product cover at least most of our must-have workflows?
- Is the remainder something we could change our process to fit?
- Can we export all our data from the legacy system in a usable format?
- Are the long-term subscription costs acceptable at our expected size?
Our scoring checklist for deciding between custom software and off-the-shelf SaaS can help you test this objectively.
How do you protect your data during modernisation?
Treat data as its own workstream from day one, whatever route you choose. Most modernisation projects that go badly do so at the migration step, not the coding step.
- Audit the data early: duplicates, missing fields, inconsistent formats.
- Decide what to migrate, what to archive and what to delete.
- Run trial migrations into a test environment and check the results with the people who use the data.
- Keep the old system read-only for a period after cut-over, so nothing is lost.
Our step-by-step guide to data migration without losing customer data goes into each stage in detail.
What does sensible modernisation look like in practice?
Usually, it looks undramatic. On our own website we found a login rate-limit bypass caused by trusting a spoofable IP header, tightened our Content Security Policy by dropping unsafe-eval, corrected canonical tags that still pointed at an old domain, and cut portfolio image weight from 1.66 MB to 456 KB. Each was a targeted fix to a working system rather than a reason to start again. Many businesses find that a handful of focused repairs like these buys them years before a bigger decision is needed.
Frequently asked questions
How long does legacy modernisation take?
It depends on the route. Protecting or wrapping a system can take weeks, incremental refactoring runs continuously in small releases, and a full rebuild of a mid-size platform typically takes about 4–9 months. Gradual replacement spreads the effort over a longer period with less risk at each step.
Is it cheaper to refactor or rebuild?
Refactoring is usually cheaper and less risky when the business logic is still sound, because you keep what works. Rebuilding can be cheaper over the long run only if the existing architecture is blocking the business and refactoring would effectively rewrite everything anyway.
Can we keep using the old system while the new one is built?
Yes, and you usually should. Gradual replacement keeps the old system running until each part is replaced. Even with a full rebuild, plan a period of parallel running and keep the old system read-only afterwards as a safety net.
What if nobody understands how our legacy system works?
Start with a discovery exercise: review the code, database and real usage, and interview the staff who use it daily. This recovers the business rules before anyone decides between refactoring, rebuilding or replacing.
Should we move to the cloud as part of modernisation?
Often, but it is a separate decision. Moving hosting without changing the code (sometimes called re-platforming) can improve reliability and backups quickly. It does not fix code-level problems on its own.
Weighing up a legacy system?
If you are unsure whether to fix, rebuild or replace, an honest assessment of the code, data and workflows is the cheapest place to start. Browse the services we offer, then talk to us about a fixed-price assessment.