Legacy modernization without the big-bang cutover

Every few years someone proposes replacing the system that runs the business. The plan has a cutover weekend on it, usually eighteen months out. Almost none of these plans survive contact with the second year, and the ones that do tend to arrive late enough that the replacement is already dated.

A big-bang cutover asks you to be right about everything at once, with no feedback until the end.

Why the date always slips

A rewrite has to reach feature parity before it can replace anything. Until it does, it delivers nothing, so there is no natural moment to course-correct and no way to discover what the old system does under load until you are committed.

Meanwhile the old system keeps changing, because the business has not agreed to stop. Every change is a moving target the replacement has to hit as well.

Move a slice at a time instead

Put a stable interface in front of the old system and move functionality across it one piece at a time. New code handles one capability; everything else still routes to the old path. When that slice is proven, take the next one.

• Each slice is small enough to reason about and reversible on its own.
• The old and new systems run side by side, so you can compare their output on live traffic before switching.
• Feature work continues throughout. No freeze, so the business never has to agree to stop.
• If the programme is cancelled halfway, the slices already moved keep their value.

What it costs

Running two systems in parallel is more work than running one. There is routing to maintain, data to keep consistent across the boundary, and a period where engineers hold two mental models at once.

That is a real cost, and it is smaller than the cost of a failed cutover. It is also spread out, coming from a steady operating budget rather than a single capital risk taken on one weekend.

Where to start

Not with the hardest part. Start with a capability that is well understood, has clear boundaries and a low blast radius. The aim of the first slice is to build the migration machinery and prove the comparison harness, not to solve the interesting problem. Save that for slice four, once moving things across has become routine.