Replacing legacy without standstill: the cut that pays off

The sentence comes up in almost every conversation about an old system: "We know we have to deal with it — but we cannot ship nothing for two years." That is not an excuse. It is an accurate read of the political situation.

A modernisation programme without a visible result reliably loses its backing in the third quarter, usually the moment another topic becomes more urgent. Technology is rarely the reason it fails. The reason is that nobody outside IT would miss the programme if it stopped.

Why the big bang is so tempting

A full rebuild is intellectually the cleanest option: no bridges, no double maintenance, no compromises at the edges. That is exactly why it gets proposed. And exactly why it fails so often — because it requires that nothing material about the business changes for two years. That assumption never holds.

The alternative is not "rebuild more slowly" but: leave the old system running and take responsibility out of it piece by piece. That is less comfortable, because for a while you maintain two worlds. It is, however, the only variant that survives a financial year.

The first cut: three criteria

The first area carved out decides the fate of the rest. It should satisfy all three at once:

It is bounded in business terms. An area with clear edges and few dependencies into the old system. Not the hardest one, not the most central one.

It has visible benefit outside IT. A cycle time that gets shorter. An analysis that did not exist before. A process that no longer needs an Excel step in the middle. Something someone in sales or service notices and will defend when it matters.

It serves an obligation. If the area is subject to evidence requirements anyway — approvals, prices, permissions — the replacement does two jobs: modernisation, and the evidence that audit or procurement demands regardless. That turns an IT programme into one with a deadline and a sponsor.

If one of the three is missing, the cut will succeed technically and change nothing politically.

What happens between old and new

The bridge is the part that gets underestimated. Three things must be settled before the first line is written:

• Where is the truth? For each data area exactly one leading system, with a date from which it leads. Dual ownership is the most common cause of silent data errors.
• Which way does it flow? One-way synchronisation is manageable, two-way rarely is. If it has to be two-way, it needs an explicit conflict rule, not a "that basically never happens".
• When does the bridge come down? A date in the plan, not a feeling. Interim solutions without a demolition date become permanent.

What else it fails on

Missing knowledge about the old. The legacy system contains rules nobody can explain any more, but which have been right for twelve years. Fail to extract them first and you will rebuild them wrong and notice at the first month-end close.

Handover. If nobody internally is accountable after the replacement, the new system is the next legacy system within three years. The question of who carries it afterwards belongs at the start, not the end.

The limit

There are systems where the effort does not pay: stable, rarely changed, no growth expected, operating fine. An old system is not a problem as long as it blocks nobody. The trigger for a replacement should be a concrete one — a lost deal, an evidence obligation, a bottleneck — not the state of the code.

Further reading

• Modernising a monolith without stopping everything
• Event sourcing or CRUD with a history table?
• Provability as an architecture topic
• Our offers