Modernising Critical Software Without Losing Operational Control

Every modernisation programme opens with the same sentence, and the sentence is usually true: the current system cannot carry on. What almost never gets examined is the sentence that follows it, implied and undiscussed — therefore we will replace it.

Replacement trades a system nobody understands in full, but whose behaviour is known from years of observation, for a system somebody understands in full on paper and whose behaviour nobody has ever seen. To the people who operate it, that is a loss of information, not a gain. The risk in modernisation is not the choice of technology: it is the interval during which the company stops knowing precisely what its own business does.

The old system is the specification

The documentation describes the intended system. The thing that runs carries years of exceptions: the customer with a different rule for a reason nobody remembers, the correction routine somebody executes at month end, the field that means one thing before a certain date and another after it, the error behaviour that three neighbouring systems depend on without ever having told anyone. None of that is in the requirements. All of it is in production, and it is what the users call the system.

The practical consequence is that the first work of modernisation is not writing new code: it is reading behaviour. And the reading has to be done from outside — inputs, outputs, effects — because that is the only description that binds. Where the old system is wrong and the business already depends on the error, reproducing the error is a legitimate decision. What it cannot be is a decision taken by accident, by someone who did not know they were taking one.

Strangle rather than replace

The known alternative is to strangle: put a seam in front of the old system, move one slice at a time behind it, and leave the rest where it is. The property that matters here is not speed, because it is slower. It is that at no point is there a system out of service: the whole stays live, and what changes at each step is small enough to fit in the head of whoever will be operating it that night.

Choosing the slices is the engineering work of this phase, and the criterion is rarely the obvious one. Slicing along the organisation chart produces boundaries that correspond to nothing in the state and dissolve at the first reorganisation. Slicing along data ownership produces boundaries that survive. The first slice has to be representative in volume and behaviour but bounded in consequence: the easiest one teaches nothing, and the most critical one collects the tuition in the worst possible place.

A migration is incremental only if each step can be undone on its own. Otherwise it is a replacement delivered in instalments.

There are two predictable traps in this shape. The seam tends to become permanent, which is perfectly acceptable provided it was designed as a boundary and not as temporary scaffolding — permanent temporary scaffolding is the origin of half the technical debt usually blamed on haste. And duplicated state, the period in which both systems hold the same information, is the hardest part of the whole exercise. The rule that avoids disaster is easy to say and expensive to keep: for each piece of state, exactly one side owns the write at any moment, and the other reads from it. Writing on both sides and reconciling afterwards is the most reliable method yet devised for producing two wrong systems.

Parity has to be observable

Saying the new one does the same thing is not a claim anyone can verify by inspection. Parity is a measurement: run both sides, compare, and have decided beforehand what counts as a difference. Four things have to be agreed before the first comparison, and all four are cheap before and become an endless argument after:

• —What is compared: the observable effect, not the internal structure. Two correct implementations differ in shape, and comparing shape produces noise without end.
• —What counts as an acceptable difference — rounding, ordering, timestamps — written down beforehand rather than on the day the difference appears.
• —Who adjudicates: someone with the authority to declare that the new system is right and the old one was wrong. Without that role, every divergence becomes a technical debate nobody closes.
• —For how long: one full business cycle, because what diverges most are the processes that run once a month, or once a year, and that nobody remembered to list.

The uncomfortable discovery of every parallel run is always the same: a good share of the differences reveal defects in the old system, and someone, somewhere, already depends on each of them. Each difference stops being a technical problem and becomes a business decision with an owner and a date. Taking those decisions before cutover is very nearly the whole value of running in parallel. Taking them afterwards has a different name, and the name is incident.

Reversibility at every step

A rollback plan that is written in the document and has never been executed is not a rollback plan. It is an intention wearing the appearance of a control, and it is usually revealed as an intention at the only moment when that matters. Reversibility gets tested while it is cheap — on the first step, with little at stake — because that is the only time when testing it is not itself an operational event.

It also has a shelf life. From the moment the new system writes state the old one cannot read, going back stops being free and becomes a migration in the opposite direction, performed under pressure and without preparation. That point exists in every crossing and cannot be designed away. The difference between teams is not avoiding it: it is knowing it in advance, saying it out loud, and treating the date as what it is — the moment the project changes character and starts to demand a different kind of attention.

The point at which going back stops being possible exists in every migration. What separates teams is knowing its date.

Modernisation done well is long and undramatic, and week by week the organisation can still answer the same four questions: what is running now, who answers for it, what changes tonight, and what happens if we switch it off. Those are operational questions rather than architectural ones, and they are how you tell whether control was preserved. The dramatic version is the one that trades, over a weekend, a known system for a newer unknown one — and an unknown system is the same system with less information, which is the exact opposite of what modernisation was supposed to buy.