Rip and Replace vs Modernise Around the Edges

Two suppliers look at the same ageing system. One proposes replacing it. One proposes leaving it where it is and building around it. Both are competent, both are being honest, and their quotes differ by a factor of six.

This is not usually a disagreement about technology. It is a disagreement about which problem you are solving, and it is worth understanding before you pick, because the bigger option is sold considerably harder than the smaller one.

This article is part of our guide to modernising a legacy business.

What each approach actually means

Rip and replace means the old system stops being used. Data is migrated, processes are redesigned to fit the new tool, everyone is retrained, and at some point there is a cutover weekend.

Modernising around the edges means the old system stays exactly where it is, doing what it already does well. New capability is added alongside it, connected by integrations, and the old system is gradually demoted from "the system" to "one of the systems".

The second approach goes by various names, none of them appealing: strangler pattern, incremental migration, wrapping. The unglamorous name is part of why it gets proposed less often.

The honest comparison

	Rip and replace	Modernise around the edges
Typical cost	£40,000 to £250,000+	£5,000 to £30,000 per step
Time to first benefit	6 to 18 months	4 to 10 weeks
Risk if it goes wrong	Business-stopping	Contained to one process
Disruption to staff	High, all at once	Low, spread out
Ongoing complexity	Lower once finished	Higher, more moving parts
Reversible	Not really	Yes, mostly
When it is right	The core is genuinely unfit	The core works, the edges do not

When rip and replace is genuinely the right call

We propose it less often than most firms, but there are four situations where it is correct and the incremental route is a false economy.

The system is out of support and cannot be secured. If the supplier has gone, the platform no longer receives updates, and it holds customer data, this is not a modernisation decision. It is a risk decision with a deadline.

The data model is fundamentally wrong. If the system cannot represent something your business now does, and has been patched into contortions to cope, wrapping it preserves the contortion. A distribution business that has moved into subscriptions with a tool that only understands one-off orders is in this position.

The integration cost exceeds the replacement cost. Some older systems have no usable API, no export beyond a fixed report, and no database access. Building around them means screen-scraping or manual bridges, which are fragile and expensive to maintain. At that point wrapping costs more over three years than replacing.

You are already replacing the process. If the way you work is changing anyway, because of a merger, a new service line or a regulatory change, the disruption is happening regardless. Doing both at once is cheaper than doing them consecutively.

When to modernise around the edges

Everything else, which in practice is the majority of cases.

The strongest argument is not cost, it is reversibility. An incremental step that does not work costs you the build price and a few weeks. A replacement that does not work can take the trading year with it. When you are uncertain, and most owners are, the cheaper mistake is the one to be able to afford.

The second argument is that it produces evidence. Six weeks in, you know whether this supplier is any good, whether your team will adopt anything, and whether the numbers you assumed were real. That information is worth having before committing to a larger programme, and a replacement project gives you none of it until it is too late to act.

The question that settles it

Ask this: if we changed nothing about the old system, and simply stopped people having to touch it, would the problem go away?

If yes, modernise around the edges. The system is not the problem, the human interface to it is.

If no, and the issue is that the system cannot hold the information the business now needs, then the edges will not save you.

The hybrid that usually wins

In practice most established businesses end up somewhere between, and deliberately so.

Wrap first, replace later, with the wrapping designed so that replacement becomes easier rather than harder. That means integrations that go through a clean boundary rather than reaching directly into the old system's internals, and data extracted into a form you own rather than left where it is, which is the central argument in vendor lock-in.

Done well, you get benefit in six weeks, you learn what you actually need from a replacement, and when you eventually do replace, half the migration work is already done. Done badly, you build a tangle that makes replacement more expensive than it was at the start, which is why the boundary matters.

Key Takeaways

• The two approaches solve different problems. Rip and replace fixes a system that cannot represent your business. Wrapping fixes a system people should not have to touch.
• Cost differs by roughly an order of magnitude, but reversibility matters more. A failed incremental step costs weeks. A failed replacement can cost the trading year.
• Replace when the system is unsupportable, the data model is genuinely wrong, integration costs more than replacement, or the process is changing anyway.
• Wrap in every other case, and design the wrapping so a future replacement gets easier rather than harder.
• If stopping people touching the old system would solve the problem, the old system is not the problem.

Frequently Asked Questions

Our supplier says our system is end of life. Is that true?

Sometimes, and it is also the most common sales line in the sector. The verifiable version is a published end-of-support date from the vendor. Ask for it in writing. "No longer strategic for us" and "we would rather you moved" are commercial statements, not technical ones.

Does wrapping just delay the inevitable?

Often, yes, and that can be exactly right. Delaying a £150,000 decision by three years while taking the operational pain away for £20,000 is good business, particularly if the delay means you eventually buy with a much clearer idea of what you need.

How do we stop the incremental route turning into a mess?

Two rules. Every integration goes through one agreed boundary rather than each new tool reaching into the old system separately. And every step must leave you with your data in a form you control. Follow both and the tangle does not form.

---

Not sure which of the two your situation calls for? Talk to Halo Technology Lab. Our strategy and scoping service will tell you when replacement is genuinely necessary, including when that means not hiring us to build one.