Legacy System Modernisation: When to Rebuild, Refactor, or Replace

Every business with software older than about five years eventually has this conversation: the system still works, mostly, but every change takes longer than it should, one person understands how it really fits together, and nobody wants to be the one who breaks it. The question is never really “is it bad enough yet” — it is which of three paths gets you out of that position with the least risk.

Three paths, not two

• Refactor. Improve the internal structure of the existing codebase without changing what it does externally. Lowest risk, lowest cost, but limited by how sound the underlying architecture already is — you cannot refactor your way out of a fundamentally wrong data model.
• Rebuild. Replace the system entirely with a new one, usually on modern infrastructure and a current data model, migrating data and cutting over. Highest risk, highest cost, but the only real option when the architecture itself — not just the code quality — is the problem.
• Incremental (strangler-fig) migration. Build the new system alongside the old one, moving one capability at a time behind a stable interface, until the old system has nothing left to do. Slower to reach full completion, but each slice ships independently, so risk is spread across many small releases instead of one large cutover.

The signs that point to each one

Refactor is enough when…

• The data model still genuinely reflects how the business works today.
• Performance and reliability are acceptable — the pain is development speed, not uptime.
• The technology stack is still supported and has a viable hiring market.
• The problems are concentrated in a few identifiable modules, not spread evenly across the whole system.

Rebuild is justified when…

• The data model no longer matches the business — you are working around it with spreadsheets, manual reconciliation, or duct-taped exports.
• The technology is end-of-life or unsupported, and hiring for it is getting genuinely difficult.
• Every new feature requires touching the same fragile core, and testing cannot keep up with the rate of regressions.
• Compliance or security requirements have moved past what the current architecture can reasonably support.

Incremental migration is right when…

• The system is business-critical and cannot tolerate a big-bang cutover — most operational and revenue-generating systems fall here.
• Different parts of the system have very different levels of technical debt — some genuinely fine, some genuinely broken.
• You need to keep shipping business value throughout the migration, not pause feature work for a year.
• The organisation needs to build confidence in the new approach before fully committing budget to finishing it.

What the strangler-fig pattern actually looks like

Named after strangler fig vines, which grow around a host tree until the original is no longer needed, this is the pattern most experienced engineering teams reach for on business-critical systems, because it turns one high-risk project into many low-risk ones:

• Put a routing layer (a proxy, an API gateway, or feature flags) in front of the existing system.
• Identify the highest-value, lowest-risk capability to move first — usually something with clear boundaries and heavy manual workaround already.
• Build that capability new, route a subset of traffic to it, verify behaviour matches, then cut over fully.
• Repeat, capability by capability, until the legacy system has nothing left doing real work.
• Decommission the legacy system — often the most satisfying step, and one that frequently never gets scheduled if it is not planned for explicitly.

The trade-off is time: a strangler-fig migration for a genuinely large system can run 12-24 months end to end. The upside is that value ships every few weeks throughout, rather than everyone holding their breath for one release day.

The real cost of doing nothing

The reason legacy systems survive budget reviews that a rebuild would not is that their cost rarely shows up as a single number — it is distributed across engineering time spent on workarounds, the operational risk concentrated in whoever understands the system, and the opportunity cost of integrations and automations you cannot safely build on top of it. None of that appears in a P&L line the way a rebuild’s price tag does, which is precisely why it survives.

A useful exercise: track, for one month, every time someone says some version of “we can’t do that because of how the old system works.” That list is usually a more accurate cost estimate than any theoretical calculation.

Regulated data and UK-specific risk

If your legacy system holds personal data, financial records, or health information, modernisation carries compliance weight beyond the technical decision. GDPR data-mapping obligations apply regardless of which path you choose, but a rebuild or migration is also the natural point to fix historical compliance debt — access controls that were never quite right, audit trails that do not actually cover everything they should, data retention that has quietly never been enforced. Businesses under FCA or NHS Digital Technology Assessment Criteria (DTAC) requirements should treat modernisation as the point to bring documentation up to current standard, not just the code.

How long modernisation actually takes

Timelines vary enormously by path and by how much of the system is genuinely load-bearing, but as a rough guide for a mid-size business system:

• Refactor: 6-14 weeks per major module, often deliverable incrementally without a formal cutover.
• Rebuild: 4-9 months for a mid-size system, longer for anything with heavy regulatory or integration surface area.
• Incremental strangler-fig migration: 12-24 months to full completion, but the first user-visible improvement usually ships within 6-10 weeks of starting, which is what makes it easier to get budget approval for than a rebuild with no visible progress until the end.

The honest answer to “how long will this take” almost always depends more on how quickly decisions get made internally — sign-off on scope, access to the people who understand the old system, availability of test data — than on engineering effort alone. Migrations stall on organisational bottlenecks at least as often as technical ones.

Signs it is time to act now, not next year

• A key supplier or platform you depend on has announced end-of-life for the technology your system runs on.
• You are turning down integration requests from customers or partners because the old system genuinely cannot support them.
• One person’s holiday or departure would put a business-critical process at real risk.
• A compliance deadline (a new FCA requirement, an NHS DSPT renewal, a GDPR audit finding) is forcing the conversation regardless of appetite.
• The cost of the workaround — the manual reconciliation, the duplicate data entry, the spreadsheet nobody officially owns — has become larger than a competent engineer’s salary.

None of these alone is a fire alarm, but two or more together are usually a reliable signal that the cost of waiting has quietly overtaken the cost of acting.

Frequently asked questions

Can we keep the old system running during a rebuild?

For a genuine rebuild, usually yes, right up until cutover — the two systems run in parallel and you switch over once the new one is verified. The risk is data drift between the two if both are being actively used during the build; a clear data-freeze or one-way sync plan for the cutover window avoids this.

What if we cannot find anyone who understands the old system?

This is more common than most businesses expect, and it is itself the strongest argument for starting modernisation now rather than later — the knowledge gap only widens. Reverse-engineering behaviour from the running system and its data is slower and more expensive than working from documentation or institutional knowledge, but it is a solvable problem, not a blocker.

Is a rewrite ever the wrong choice even when the system is genuinely bad?

Yes — when the business cannot tolerate the delivery risk of a big-bang cutover, even a genuinely poor system is often better served by incremental migration, precisely because it spreads risk across many smaller releases instead of one large one.

How do we get buy-in for a modernisation project internally?

Quantify the workaround cost, not just the theoretical benefit of the new system — the one-month tracking exercise mentioned above is usually far more persuasive to a budget holder than an abstract architecture diagram.

A practical checklist before you decide

• Map what the system actually does today, including the manual workarounds nobody documented.
• Identify which parts are genuinely load-bearing versus accumulated exceptions that could simply be dropped.
• Get an honest technical assessment from someone with no incentive to recommend the most expensive option.
• Price at least two paths (rebuild vs incremental) before committing, since the right answer is rarely obvious from the outside.
• Plan the decommissioning step from day one — legacy systems that “will be turned off eventually” frequently never are.

If you are weighing this decision and want a straight technical opinion rather than a sales pitch for the most expensive option, we are happy to look at the system with you — get in touch and we will give you a direct answer either way.