Insights · 12 June 2026

How to replace a legacy system without a big-bang rewrite

The riskiest way to replace an old system is all at once. Here is how we retire legacy software one workflow at a time, while the business keeps running.

Every organisation has one: the system nobody dares touch. It runs something important, the person who built it left years ago, and the vendor stopped answering the phone. Everyone agrees it has to go. The question is how to do that without stopping the business.

The instinct is the big bang: spec a replacement, build it for eighteen months, migrate everything one weekend, switch off the old system on Monday. It feels decisive. In practice it is the highest-risk move available, because nothing is proven until everything is finished, and by then the requirements have moved.

There is a calmer way. We have used it across housing, manufacturing and media, and it looks like this.

Start by connecting, not replacing

Before changing anything, get the data out. Build an integration that reads from the legacy system and puts its data somewhere modern and visible, a proper reporting layer or a simple API. Nothing about day-to-day work changes yet, but two things happen: you finally see the quality of the data you will one day migrate, and every new thing you build from now on has a live feed instead of a rekeying job.

Take one workflow, not one system

Pick the workflow that hurts most, not the whole platform. One team, one process, one measurable outcome. Build the replacement for that workflow only, integrated with the legacy system where it must be, and put it live. The old system keeps doing everything else.

This matters because it shrinks the bet. If the new workflow is wrong in some way, you find out in weeks, on one process, with one team, while everything else still works.

Let trust retire the old system

Repeat workflow by workflow. Each cycle moves more day-to-day work onto the new system, and the legacy platform quietly becomes a database that fewer and fewer people log into. Migration stops being a cliff edge and becomes a series of small steps you have already rehearsed, because the integration you built first has been exercising that data for months.

The final switch-off becomes an anticlimax. That is the goal. Nobody should remember the weekend you replaced the system, because there should be nothing to remember.

What this asks of you

Patience, mostly. The big bang promises everything at a single future date; this approach delivers something real every few weeks but asks you to live with coexistence for a while. In exchange, you never bet the business on an unproven system, your team learns the new world gradually, and if priorities change mid-journey you have working software, not a half-finished rewrite.

If you have a system nobody dares touch, that is usually the sign it is time. Tell us what it runs and we will tell you honestly where we would start.

Talk to us

Do you have a similar problem?

Tell us the problem you want to solve. Our UK team will give you an honest view.

Get in contact