There is a conversation that happens in almost every company running software older than ten years. Someone — often a new technical hire, sometimes a frustrated director — looks at the creaking system that runs the business and says: "We should just rewrite it." It sounds decisive. It sounds clean. And in our experience, it is usually the most expensive mistake on the table.
Legacy system modernisation is most of what serious software work actually is. Very few businesses get to start from a blank page; most are carrying a system that works well enough to be indispensable and badly enough to be resented. This post is about how to replace that system without betting the company on a single cutover weekend — and about the rarer cases where a clean rewrite genuinely is the right answer.
Why big-bang rewrites fail
A "big rewrite" — or big-bang legacy software replacement, if you prefer the formal term — means building a complete new system in parallel, then switching everything over at once. The failure modes are well documented and depressingly consistent.
The second-system effect
The team rebuilding a system they already know tends to design for every frustration they ever had with the old one. Every shortcut gets corrected, every "we should have" gets included, every speculative future requirement gets an abstraction. The result is a second system that is more ambitious, more complex, and slower to deliver than the first — a pattern Fred Brooks named the second-system effect over fifty years ago. It has not gone away.
The target keeps moving
The old system does not freeze while you rebuild it. The business still needs new features, regulatory changes still land, customers still report bugs. So either the old system keeps evolving — and the rewrite is chasing a moving target it can never quite catch — or the business accepts a feature freeze that gets harder to justify every quarter. We have seen rewrites where, by year two, the new system was further from parity than it was at the start.
Hidden business rules surface at the worst moment
Old code accumulates decisions nobody wrote down. That odd rounding behaviour in the invoicing module is not a bug — it matches a 2014 agreement with your largest customer. The strange validation rule exists because of a fraud incident everyone has forgotten. In a big-bang rewrite, you discover these rules at cutover, in production, with real customers, all at once. The old system was the only complete specification of itself, and you just turned it off.
Years with nothing shipped
This is the failure that kills rewrites politically rather than technically. A big rewrite delivers nothing until it delivers everything. For eighteen months or three years, the business pays two costs — maintaining the old system and building the new one — and receives no visible benefit. Budgets get questioned, sponsors move on, and a half-finished rewrite is worth almost nothing. Plenty of companies end up running the old system and fragments of the abandoned new one, which is strictly worse than where they started.
The strangler-fig pattern, in plain English
The alternative has an evocative name. A strangler fig is a plant that grows around a host tree, gradually taking over its structure until the original tree is gone and the fig stands on its own. Applied to software, the idea is simple: the new system grows around the old one, taking over responsibility piece by piece, until one day the old system has nothing left to do and can be switched off almost as an afterthought.
Mechanically, it usually works like this:
- Put a routing layer in front of the old system. This might be a reverse proxy, an API gateway, or routing logic in the application itself. At first it sends 100% of traffic to the legacy system — nothing changes for users.
- Build one piece in the new system. A single screen, a single API endpoint, a single report. Something small with clear edges.
- Move that route over. The routing layer now sends requests for that one piece to the new code. Everything else still goes to the old system. If something goes wrong, you flip the route back in minutes, not days.
- Repeat. Route by route, module by module, traffic migrates. The old system shrinks in importance without ever being torn out.
The decisive advantage is that every step is small, reversible, and shipped. You get value early — often within weeks — and the business never has a moment where everything depends on one untested cutover. Hidden business rules still exist, but you discover them one module at a time, while the old system is still running and can be checked against.
The honest caveats: the strangler approach requires discipline, and it requires that someone holds the whole picture in their head — old system, new system, the routing layer, and the data flowing between them. Data is the hard part. While both systems are live, you need a clear answer to "which system owns this record?", and that answer has to hold under failure. This is where most strangler migrations get into trouble, and it is exactly the kind of end-to-end systems problem we are built for. Hyperfocus is genuinely useful here: tracing one invoice through a fifteen-year-old codebase to understand why it rounds the way it does is tedious work for most teams and absorbing work for ours.
Sequencing by risk: where to start
Not all modules are equal, and the order in which you migrate them is most of the strategy. Two rules cover most of it.
Start with read-only views
The safest possible first step is something that displays data without changing it — a dashboard, a search screen, a report. If a read-only view has a bug, someone sees a wrong number and tells you; no data is corrupted, no order is lost, no money moves incorrectly. Read-only work also forces you to solve the unglamorous foundations — authentication, access to legacy data, deployment, monitoring — while the stakes are low. By the time you migrate something that writes data, the plumbing is proven.
This is also where modern web application development earns its keep quickly. A fast, well-designed read layer over legacy data is often the most visible improvement users get in the entire project, and it ships in the first month rather than the last.
Then lowest-risk, highest-pain
Plot every module on two axes: how much it hurts the business today, and how dangerous it would be to get wrong. Migrate the ones that are high-pain and low-risk first. Imagine a distributor whose stock-lookup screen takes thirty seconds to load and infuriates the warehouse team daily, but whose payment processing works fine and touches real money. The stock screen goes first — maximum relief, minimal blast radius. Payments go near the end, when the team has a dozen successful migrations behind it and the tooling is battle-tested.
What you should not do is start with the hardest module "to de-risk the project". The hardest module is hardest precisely because it is full of hidden rules and tangled dependencies. Earn the right to touch it.
When a rewrite is the right call
We are opinionated about this, but not dogmatic. There are real cases where a clean rewrite beats incremental migration:
- Genuinely small systems. If the whole thing is a few thousand lines and one developer can understand it completely in a fortnight, the overhead of routing layers and parallel running exceeds the cost of just rebuilding it. Strangler patterns are for systems too large to hold in one head.
- Dead platforms. If the system runs on a language, framework, or operating system that is no longer maintained — no security patches, no available developers, no way to hire — incremental migration may be impossible because you cannot safely change the old side at all. Sometimes the host tree is already dead.
- Security cliff edges. If the legacy system has unfixable vulnerabilities, fails a compliance requirement with a hard deadline, or handles data in a way that is now indefensible, the timeline is set by the risk, not by engineering preference. A focused rewrite of the exposed surface — note: the exposed surface, not necessarily everything — can be the only responsible option.
Even in these cases, the rewrite should be scoped ruthlessly: rebuild what exists, resist the second-system urge to "improve" everything at once, and ship improvements as a second phase once parity is proven.
Keeping the business running throughout
Whatever the approach, the non-negotiable constraint is that the business keeps operating. A few practices make that realistic:
- One writer per record. At any moment, exactly one system is the source of truth for any given piece of data. Both systems may read; only one writes. Ambiguity here is how migrations corrupt data.
- Reversibility as a requirement. Every migration step needs a tested way back. If a route cannot be flipped back to the legacy system, it is not ready to flip forward.
- Run in shadow before you cut over. For high-stakes modules, run the new code alongside the old, compare outputs on real traffic, and only switch when they agree. Discrepancies found in shadow mode are free; discrepancies found in production are not.
- A narrow, honest feature freeze. You usually cannot freeze the whole legacy system, but you can freeze the module currently being migrated. Keep the frozen zone small and the freeze short.
- Tell users what is changing and when. Most migration pain reported by users is actually surprise. A two-line email beats a perfect rollback plan you never needed.
None of this is exotic. It is mostly the patient application of systems thinking: seeing the old system, the new system, the data, and the people who depend on them as one whole, and refusing to break any part of it for the convenience of the project plan. That end-to-end view — and the pattern recognition to spot the landmines in an unfamiliar codebase early — is the core of how we approach legacy modernisation, and frankly it is the kind of work our brains are wired for.
Talk to us before you commit to a rewrite
If you are weighing up a legacy migration — or you are partway through a rewrite that has stopped feeling like a good idea — a second opinion is cheap and the alternative is not. We do software development in Cambridge and remotely across the UK, and we are happy to look at a system and tell you honestly whether it needs a strangler, a rewrite, or just six weeks of targeted repair. Email us at hello@overclockminds.co.uk or use the contact page. No deck, no pressure — just send a description of the system and what is hurting.