The load-bearing legacy system

The system everyone agrees should be replaced

Most enterprise operations contain at least one system that is old, poorly documented, expensive to change, and absolutely load-bearing. Everyone agrees it should be replaced. It has been on the roadmap for several years. It is still there.

The reason it is still there is rarely technical. Replacement programmes fail on organisational grounds: the system encodes process knowledge that exists nowhere else, the people who understood it have left, the cutover cannot happen without stopping operations, and the business case requires a period of double-running that nobody wants to fund.

Meanwhile the cost of keeping it is real and rising — integration workarounds, manual bridges between it and everything newer, and an operational risk that grows each year as the pool of people who can touch it shrinks.

The useful question is not how to replace it. It is how to stop being blocked by it.

Strangle, do not replace

The pattern is well established in software architecture and translates directly to operations. Rather than building a replacement and switching over, you build capability alongside the existing system, route traffic to the new capability incrementally, and let the old system's responsibility shrink until what remains is small enough to retire or cheap enough to keep.

Applied to an operation rather than a codebase, it looks like this:

Put an integration layer in front of it. Everything new talks to the layer; the layer talks to the legacy system. This is a modest piece of engineering with a disproportionate effect: it decouples every future project from the legacy system's interface, which means the next five initiatives no longer each pay the cost of understanding it.

Move responsibilities out one at a time. Pick a bounded function — a report, a calculation, an intake path — and implement it outside the legacy system, reading and writing through the layer. Run both in parallel until the new path is trusted.

Let the old system shrink. After several such moves, what is left is often much smaller than the original. Sometimes it becomes small enough to replace with a straightforward build. Sometimes it becomes cheap enough that nobody minds keeping it, which is a legitimate and underrated outcome.

Instrument as you go. Each move should reduce a measurable cost — manual touches, cycle time, integration effort. If a move does not reduce anything measurable, it was sequenced wrong.

What this buys, and what it costs

It buys: no big-bang cutover, no period where the business is betting on a single weekend; incremental value rather than value deferred to the end of a multi-year programme; a rollback path at every step; and the ability to stop when the return stops justifying the spend, having kept everything delivered so far.

It costs: a period — often years — of running an integration layer that is itself an asset requiring ownership and maintenance. Some duplication of logic between old and new during transition. And a discipline problem, because a phased programme with no forcing function can drift indefinitely if nobody holds the sequence.

That last risk is the serious one. Phased modernisation without a named owner and a reviewed sequence does not fail loudly; it just stops progressing while everyone assumes it is still underway.

Where AI fits, and where it does not

There is a specific and valuable role for automation here, and a much larger set of claims that should be treated sceptically.

Valuable: using document intelligence and workflow automation to remove the manual bridges people have built around the legacy system. The spreadsheet that reconciles two systems. The rekeying between the portal and the mainframe. The email that carries a status update because the systems cannot. These are frequently the highest-return items on a modernisation roadmap and they do not require touching the legacy system at all.

Treat sceptically: claims that AI can reverse-engineer, document or rewrite the legacy system for you. Tools can help a competent engineer read unfamiliar code faster. They do not recover the business reasoning behind a rule written in 1997, and it is the reasoning, not the code, that is the actual missing artefact.

The honest sequence is usually: remove the manual bridges first, because they pay back quickly and reduce risk; put the integration layer in second; move responsibilities third.

Starting

1. Map what depends on it. Every downstream system, report, and manual process. This is usually the first time the true dependency surface is visible on one page, and it frequently changes the plan.
2. Cost the workarounds. The manual bridges have a number attached. That number is the budget for the first phase, and it is often larger than anyone expected.
3. Find the bounded function to move first. Something with a clear boundary, a measurable cost, and low blast radius. Do not start with the hardest thing to prove you can.
4. Name the owner and the sequence, with a review date. Phased programmes fail from drift, not from technical difficulty.
5. Decide the stopping condition now. At what point is the remaining legacy system acceptable? Programmes without a defined end run until the budget ends instead.