Modernising a core system without taking it offline

Every modernisation programme begins with somebody drawing a plan where the new system replaces the old one over a long weekend. It is a perfectly reasonable plan on a whiteboard. It survives until the first person asks what happens if the reconciliation has not balanced by Sunday evening, and there is no answer anyone is willing to put their name to.

So the work gets shaped differently. Cut over a piece at a time, keep every step reversible, and prove the case again at each step before asking for the next. The pattern has a name, the strangler, and describing it takes one sentence. Running it takes two years, and most of the difficulty lives in places that sentence does not mention.

The seam is the architecture decision

A staged migration needs somewhere to intercept traffic and decide whether a request goes to the old system or the new one. That interception point is the design. Everything else follows from it.

There are usually three candidates. A facade at the network edge, routing by URL or message type, which is clean and works when the old system has a well-defined external interface. A shim inside the application, which is what you end up with when the old system is a monolith whose only interface is a function call. And, at the bottom, the database, where the seam is a view or a replication stream and the two systems argue over the same tables.

The database seam is the one teams reach for, because it looks cheapest and requires no cooperation from anybody. It is the one we avoid where we can. Two systems writing to shared tables means the invariants live in neither of them, and the first production incident is a race condition nobody can reproduce. Where we have had no choice, we have made one side the sole writer and the other strictly a reader for the whole dual-run period, and accepted the staleness that implies.

If the old system has no seam at all, and plenty do not, the first months of the programme go on building one. That work delivers no visible feature. It has to be sold as such, at the start, to the person signing the invoices. A programme that hides it inside a phase called discovery will lose that argument in month four, at the first steering committee that asks what has shipped.

Slice by population, not by function

The instinct is to migrate function by function: payments first, then billing, then reporting. That is the wrong axis. Functions are entangled with each other, so a function-first cutover puts a single transaction across both systems on day one, which is the exact condition the staged approach exists to avoid.

Slicing by population works better. One region, one product line, one class of customer, one tenant. That group takes its whole journey through the new system while everyone else stays on the old one. Failures are contained to a set of people you can name and telephone. Rollback is a routing rule. The comparison between old and new is like for like, because both populations are doing the same work in the same week under the same conditions.

Choose the first slice for observability rather than for size. The best first slice is the one where somebody will notice quickly and say so plainly. An internal team beats a small external market you have no relationship with, every time.

Dual run is where you find out what the old system actually does

For a period, both systems process the same input. The new one runs in shadow: it receives the traffic, does the work, writes to its own store, and its output is compared rather than used. Later the flow reverses, and the old system runs behind the new one for a while as insurance.

Everyone budgets for that comparison to be dull. It never is. On every programme of this kind we have run, the differences are dominated by the old system doing something nobody documented and nobody remembers deciding. Rounding applied at a different point in the calculation. A timezone handled one way in the batch job and another way on the screen. A discount rule that fires when a field is empty rather than when it is zero. A tax band corrected in the specification years ago and never in the code.

Each difference then becomes a business decision rather than a bug report. The old behaviour has been in production for a decade. Customers have been billed under it. Accounts have been closed on it. Reproducing a known defect in a clean new system feels wrong to every engineer on the team, and is frequently the correct answer, at least until a separate, deliberate, dated change fixes it for both sides. The mistake is fixing it quietly during the migration, because then the cutover and the behaviour change land in the same week and nobody can tell which one caused the complaint.

Reconciliation is a product nobody budgets for

Comparing two systems at volume needs software. A harness that replays traffic to both. A normaliser that strips out the differences already agreed to be irrelevant. A store for the differences that remain. A triage interface where a person classifies each one. And then somebody whose actual job, every morning, is working that queue.

That is a small product with a backlog, an owner, a user interface and a support cost, and it appears in no business case we have ever been shown, because it produces nothing a customer will ever see. We now put it in the plan as a named workstream with its own estimate. Clients push back on it roughly half the time. The ones who cut it spend the same money later, in incident hours, at a worse moment.

Reversible means the rollback has actually been performed

Reversibility is the property that makes staged cutover safe, and it is usually asserted rather than tested. A routing flag that has never been flipped back under load is a hypothesis. We flip it deliberately, during a quiet period, with the client watching, before we get anywhere near the slice that matters.

Reversibility also carries a data cost that teams underestimate. Rolling a slice back requires the old system to have stayed current, which means writing to both sides for the whole period, which means the write path is more complicated during migration than it was before or will be after. Teams who skip the double write keep a rollback plan that works for about an hour, until new data exists only on the new side. After that the plan is roll forward and hope, which is not a plan.

The old system stays alive longer than the plan says

Traffic stops arriving through the front door long before anything can be switched off. Batch jobs still run. A report finance runs on the last working day of the month still points at the old database. A downstream team you have never met is reading a table directly, because somebody issued them credentials years ago and wrote it down nowhere. Decommissioning is its own piece of work with its own budget, and treating it as the tail end of the migration is how organisations end up running systems for years after declaring them retired.

It costs more in total, and that is the trade

A staged migration is more total effort than a rewrite. You pay for the seam, the dual run, the reconciliation product, the double writes, and the cost of operating two platforms simultaneously for as long as it takes. Anyone claiming otherwise is selling something.

What the money buys is that the service never stops and every step can be undone. For a system a business cannot trade without, or one where the citizen has no option to go elsewhere, that is usually the only acceptable trade. It has a second benefit that shows up in the numbers: because each step is small enough to validate before the next is funded, the benefits tend to hold. On a loan operations programme for a retail bank, we ran the rollout in phases with a pilot validating each expansion before it was widened, and the numbers that came out of it were around 60 per cent off processing time and 40 per cent off operating cost.

The failure mode we have been part of

The characteristic way a strangler fails is stalling, and a botched cutover has very little to do with it. The high-value slices move first, because that is the sensible order. The benefit gets realised, the sponsor gets the outcome they wanted, and the last few modules sit behind the facade unfunded, competing for budget against new features and losing every time. Both systems then live indefinitely, and the organisation carries the cost of two platforms plus the routing layer holding them together.

We have been on the wrong side of that, and the fault was ours as much as the client's. We had scoped the early phases precisely and left the final ones as a phase three with no date attached. The correction was contractual as well as technical: the end state is a milestone with a date on it, the facade has a planned removal, and the last slices get scoped and priced at the start alongside the first. A migration with no defined end is a permanent second system with a project name attached to it.

The whole approach rests on an unfashionable idea. The machinery that lets two systems disagree, in public, for eighteen months, without anybody outside noticing, is where the real engineering in a modernisation programme sits. The new system is the easy half.