Choosing the first piece to replace

Of everything that needs rebuilding, how do you decide what goes first?

A system of two million lines is to be replaced incrementally. Everyone agrees on incremental. Nobody agrees on what goes first.

Two answers arrive immediately and both sound obviously right. Start with the highest-value area, because that is where the return is. Or start with the easiest, because early success buys credibility. Notice they are answers to different questions — one optimises the payoff of the slice, the other its probability of completion — and neither asks what the first slice is actually for. That turns out to be the question worth putting first.

Consider what the first slice has to build that later slices do not. To run any piece of new code alongside the old system you need a place to intercept traffic and route it, a way to keep data consistent across both sides, a deployment path, monitoring that can compare old and new behaviour, and a way to route back when it misbehaves. Every one of those is a one-time cost, and every one is paid by whichever slice goes first.

So the first slice's real product is that machinery. The functionality it delivers is almost incidental by comparison — which reframes the selection. You are not choosing the most valuable piece; you are choosing the cheapest honest test of the whole approach.

What does honest mean here? Take the seductive alternative: a small, low-risk, internal report with no users. It builds quickly and proves nothing, because it skipped authentication, skipped the write path, skipped data synchronisation, skipped the compliance review. Every hard thing has been deferred, and deferred hard things do not get cheaper. The first slice must therefore be thin but complete — it must pass through every layer, take real production traffic, and exercise the parts everyone is nervous about, precisely because those are the assumptions worth testing while the investment is still small.

That gives a first criterion. What gives the second?

Ask what makes one slice cost five times another of the same size. Rarely the code volume. Usually the entanglement — specifically, shared data. A component with a clean existing interface can be intercepted at that interface. A component whose state lives in tables that forty other programs also read and write has no seam; carving it out means either replicating those tables both ways or moving the forty programs. Coupling through data, more than any measure of size or complexity, predicts the cost of a slice, so it belongs in the selection at the same weight as value.

Now cross those with value and a pattern appears. The piece that is both most valuable and most entangled is the worst possible opener: it is where the programme is most likely to stall, and stalling on the first slice is how these efforts get cancelled. The piece that is cheap and worthless is the second worst, for the reason above. What you want is a slice with genuine users and a genuine seam — modest value, real traffic, real writes, tractable coupling.

Two more considerations are worth adding, both easy to miss.

Reversibility. Can you route the traffic back to the old system in minutes, with no data left behind? A slice you can retreat from can be attempted with far less ceremony than one you cannot, and early on you want to be able to be wrong cheaply.

Churn. Replacing a piece nobody has touched in eight years captures no future saving, because there was no future cost. Areas under active change are where the ongoing cost of the old system actually falls, so the modernisation return is concentrated there. This one pulls against the low-risk instinct, and it is a genuine trade rather than a resolved question.

Then does the order of everything after follow? Partly, and by a different rule. Once the machinery exists, sequencing is driven mainly by data ownership: you cannot move a consumer of a dataset before the new side can serve that dataset, so the graph of who owns what largely dictates the order. Value re-enters the decision at that point, once it is no longer competing with the cost of building the road.

Three refinements.

First, a slice is a vertical, not a layer. Replacing the database first, or the user interface first, while leaving the rest, produces two systems coupled at their most intimate boundary and delivers nothing until the last one lands. Slicing by capability keeps each increment independently valuable and independently reversible.

Second, "easy" and "low risk" are not the same property and are often opposites. The easy slice is easy because it avoids the parts nobody understands. Those parts are the risk, and the point of going first is to meet some of it early while the sunk cost is small.

Third, the selection deserves to be written down with its criteria, because it will be revisited. When the second slice turns out harder than expected, the useful question is whether the criteria were wrong or the estimate was — and that is answerable only if someone recorded what was traded against what.

• How to measure data coupling well enough to compare two candidate slices before committing.
• Whether to modernise stable code at all, given that the saving accrues only where change happens.
• What the retirement criterion for the old system should be, and who is entitled to declare it met.

Every term the collection defines is gathered in the glossary.