The situation
A manufacturing client ran their old ERP and its replacement side by side for 19 months. Two sources of truth, two on-call rotations, and nobody willing to switch the old one off.
The new system worked. The build was finished. What nobody owned was the decision to kill the legacy system, and what the rollback would be if production broke at 2am. So both systems stayed alive, month after month, at real and recurring cost.
What was really going on
The usual diagnosis stops at “name a date, assign an owner”. That does not survive contact with the real blocker. The person who flips the switch is making a personal career bet under uncertainty, and no schedule removes that.
So the parallel run becomes the safe choice for everyone. Keeping both systems alive has no single name attached to it. Turning one off does. That asymmetry, not the engineering, is what stalls the cutover.
The other common piece of advice, “get leadership to sign off in writing”, fails for related reasons. Executives will not sign a frightening memo, and if the rollback plan cannot survive technical scrutiny, everyone in the room quietly knows it. A signature fixes neither the fear nor the missing plan.
What we did
We changed the two things that created the asymmetry.
First, we shrank the bet. We did not decommission the old system. We put it in warm standby with a rollback we rehearsed and timed: primary back on the legacy ERP in under 30 minutes, tested twice before cutover. That reframed the decision. It was no longer “kill it forever”, it was “switch primary, with a proven way back”. A small, reversible bet gets made. An unbounded one does not.
Second, we put a name on inaction too. The dual runtime and the second on-call rotation went onto a monthly budget line with an owner. Keeping both systems alive stopped being free and nameless. It became a specific number (roughly EUR 35,000 a month in dual-running and a second rotation) that a specific person had to defend every month.
This is the part of legacy modernisation that has little to do with code: the engineering was done long before the organisation was ready to act on it. The work that unlocked the cutover was decision design, not development.
What changed
Once the downside was bounded and the parallel run carried a price tag, the cutover happened in two weeks.
Not because anyone got braver. Because we stopped asking anyone to be brave. The figures here are openly estimated rather than audit-grade, but the shape is plain: 19 months of roughly EUR 35,000 a month in avoidable dual-running cost, ended by two changes that cost far less than a single month of the stalemate. The rehearsed rollback meant the switch carried a known, sub-30-minute downside instead of an unbounded one, and the monthly budget line meant doing nothing was no longer the comfortable option.
The lever was never the signature. It was making the safe-looking option visibly expensive and the risky-looking option cheaply reversible.
If you are mid-migration: is your rollback actually rehearsed and bounded, or are you asking someone to bet their reputation on an untested switch at 2am? The fix is completely different depending on the answer, and if you are not sure which one you are in, talk to us.