Legacy modernisation without the big-bang replacement

Why replacement projects fail

Large replacement programmes fail for a structural reason rather than a technical one: everything must work on the same day. Requirements gathered at the start have aged by the time the system is ready, the business has changed, and there is no partial success available. The programme either lands or it does not.

Incremental modernisation removes that property. Each phase is independently valuable and independently reversible.

Start with the interface, not the replacement

The first move is usually not to build anything new but to put a documented API in front of the legacy system. This does two things immediately: new development stops being blocked, and a seam is created behind which the implementation can later change without callers noticing.

It is unglamorous work and it produces no visible feature. It is also the step that makes everything after it possible.

Move one bounded area at a time

With the interface in place, capability moves behind it in bounded pieces: a module, a domain, a table group. Traffic is redirected once the replacement is verified, often gradually. The legacy system continues serving everything not yet moved.

Data is the difficult part. For a period, both systems may hold state, which requires a clear decision about which is authoritative and a reconciliation process to detect divergence. This is real work and should be planned as such rather than discovered.

Documenting what nobody remembers

Most legacy systems have outlived the people who built them. Behaviour has to be reconstructed from code, database contents, logs and the accumulated knowledge of long-serving users. We treat this as the first deliverable, because a replacement built on assumptions about current behaviour will differ from it in ways discovered by customers.

When a rewrite is genuinely right

Incremental is not always correct. A small system, on a technology that can no longer be supported, in a domain that is well understood, can reasonably be rebuilt outright. The test is whether you can afford to be wrong. If a failed cutover would seriously damage the business, incremental is the responsible choice regardless of how much longer it appears to take.

What to expect commercially

Incremental modernisation spreads investment across phases rather than concentrating it. Early phases often reduce cost (retired licences, decommissioned hardware) which helps fund what follows. It also means that if priorities change mid-programme, what has been delivered continues to work rather than being stranded.