Insights Engineering
Do not migrate in one go
Nine months to replace four systems, without stopping shipping for a single day. What made that possible was not careful planning — it was giving up on the idea of a cutover.
A cutover date is an assumption
Most migration plans are organised around a date. That evening the old system stops, the new one starts, and in between there is a stretch of time everyone is tense about. The problem is not that the risk is high. It is that every risk in the project has been compressed into one night, and the only preparation for that night is a rollback plan nobody has ever executed.
Both systems have to be right
On the Kaiho project the premise from week one was that the old system and the new one were both correct, simultaneously. Every shipment was written to both, an automated comparison ran overnight, and the differences went out as a list each morning. There was no cutover date — only a question that got answered daily: how many records disagreed today.
The real output is that list of differences
For the first six weeks the list was never empty. Every entry was a rule the specification had missed: a customs category one client used, a consolidation that only appears at month end, an exception nobody had ever written down but everyone knew. None of that surfaces in interviews. It only surfaces in data.
Convergence is the progress report
In week seven the list got shorter. By week ten it was in single figures. In week fourteen it was empty five days running, and that was the first day we discussed switching the old system off. The launch date was not scheduled — it was demonstrated. In a steering meeting, that distinction turns out to be worth a great deal.
It costs about thirty per cent more
To be plain: parallel running is not free. A second write path to maintain, another reconciliation report to read, and every change has to hold on both sides. Across the project it added roughly thirty per cent to engineering time. This is not an elegant technique. It simply converts risk into a price you can afford.
When not to do this
If nobody reads the old data, if two hours of downtime harms no one, if this is an internal tool — cut over in one go and keep the thirty per cent. Parallel running trades engineering time against downtime risk, and it only pays when downtime is genuinely expensive. That judgement belongs in the proposal, not in the incident review.