Preserve, connect or replace

When a system becomes painful, the instinct is to replace it. That instinct is sometimes right and frequently expensive — because the pain is usually concentrated in a few workflows while the rest of the system quietly works.

A replacement programme takes on all of it: the parts that hurt and the parts that do not, plus every undocumented behaviour the business has come to depend on. That is why these programmes overrun. The cost is not in the software that was specified; it is in the software nobody remembered to specify.

Most ageing systems contain four distinguishable things: data that is genuinely valuable, business rules encoded over years, an interface that has aged badly, and integration points that were bolted on later.

Those age at different rates. The interface is usually the worst of them and the cheapest to change. The encoded rules are often the most valuable and the least documented. Deciding at the level of the whole system forces one verdict on four different situations.

The more useful exercise is to take each capability and assign it one of a small set of outcomes: preserve it as-is, connect it to something else so the data stops being re-keyed, modernise the surface while leaving the logic alone, or replace it because the underlying model no longer matches how the business works.

That produces a sequence rather than a programme. Early steps deliver value without depending on later ones, and each step can be stopped or reordered as the business changes — which it will, over the life of anything large enough to need this analysis.

Retiring a system is the end of the process rather than the beginning. It should happen when the capability it carried lives somewhere else and has been observed working there — not when the replacement is declared finished.

The gap between those two moments is where most migration incidents happen.