Where the risk lands
A big-bang rewrite puts all of its risk on one night. A parallel run spreads the same risk across months, while the old system is still there to catch it.
You cannot prove a rewrite is correct until it processes real work, and a big-bang cutover switches off the only thing that could have told you.
Five stages
Map the estate
What exists, who owns it, where the risk sits.
Pick the seam
One capability. Small blast radius.
Build alongside
Behind a facade. Legacy untouched.
Run in parallel
Both process the same work.
Retire and repeat
Cut over on evidence, switch the old one off.
Stage four is where most of the work sits, and it is the stage that usually gets the least attention.
Picking a seam
Good first seam
- Output you can compare: a file, a ledger entry, a number
- Enough volume to establish a divergence rate
- Somebody actually wants it fixed
- Few downstream consumers, and you can name them
- An owner who will answer questions
Not first
- Output is a side effect you cannot observe
- The component with the worst reputation, usually the most coupled
- Anything that has to change behaviour at the same time
- Four runs a month, so a year before it tells you anything
Improving the logic while you are in there. Every difference then has two possible causes and the comparison proves nothing. Freeze behaviour, prove equivalence, cut over, then change what the system does.
Stage four, in one picture
The replacement sees production work from day one and carries none of the production risk. Compare the output, not the internals. It is allowed to reach the answer differently.
Four outcomes, four responses
| Class | Meaning | What you do |
|---|---|---|
| Match | Same result within the agreed tolerance. | Count it. |
| Tolerable | Differs in a way that is understood and does not matter: ordering, formatting, an always-arbitrary rounding step. | Encode the rule in the comparator. Never wave one through twice by hand. |
| Real | The replacement is wrong. | Fix it, add the case to the harness, keep running. Expect this to dominate early and approach zero. |
| Legacy defect | The replacement is right and the legacy has been wrong, possibly for years. | Stop. This is a business decision, not an engineering one. |
The awkward one
Class four arrives in almost every parallel run of any length, and the instinct is to make the replacement match so the run can finish. That silently bakes a known defect into a new system.
Quantify
How many records, over what period, in which direction.
Ask the outcome owner
Not the system owner. What should the answer be?
Record the ruling
In writing, dated, attributed.
Implement and mark
The comparator now expects this difference.
Teams find this uncomfortable at first. It is also one of the more useful things a parallel run turns up, because you end up with a written decision on something that had been running unexamined for years.
When to stop, and when to cut over
Flip which implementation the facade routes to. Keep the comparator running with the roles reversed for a while, so the legacy is now the one being observed. That costs almost nothing and catches the difference that only appears under real load.
Retiring, for real
Set the date at cutover
Dates negotiated after the fact tend to keep moving.
Cut the inputs first
Anything still calling it will fail loudly while the system is up and you can still look.
Archive the data
Readable without the application. Data is usually the reason an old system stays switched on.
Decommission
Licences, credentials, network, jobs, monitoring nobody will act on.
What it costs, and when not to
You reach the first cutover later than you would with a big bang. Every seam after it goes faster, because the harness, the comparator and the facade pattern already exist.