Moving a legacy system without stopping the plant

The system running an operation is usually the one nobody wants to touch. It works, it is undocumented, and the person who wrote it left years ago. Meanwhile the server it runs on is out of support and the risk compounds quietly.

The instinct is to rewrite it and switch over on a weekend. That plan fails in a specific way: you discover the undocumented behaviour on Monday morning, when the plant is running and there is no path back.

What works instead starts with tests written against the old system before anything changes. Not tests of what it should do — tests of what it actually does, including the parts that look like bugs. Some of those bugs are load-bearing. A rounding quirk in the old inventory calculation had been silently compensating for a data entry habit on the floor for six years; fixing it in the new system would have thrown off every count.

Then both systems run at once. New writes go to both, and a nightly job reconciles them and reports every disagreement. The first week produces a long list. The list gets shorter. When it reaches zero and stays there for a fortnight, cutover is a business decision rather than a technical risk, and it can happen during a normal working shift.

The last migration we ran this way cut over at 11am on a Tuesday. The plant found out when we told them.