Replacing a system people depend on daily is a logistics problem wearing a software costume. The engineering is usually the easy half.
Rehearse the cutover, more than once
We moved four hundred terabytes for a production company across six weekends without losing a shooting day, and the reason was rehearsal, not bandwidth. Every migration got a dry run against real data, a timed rollback and a named person who could call it off. Nothing about that is clever. It is simply planned.
The rules we hold to
- —Run both systems in parallel until the new one has survived a full business cycle.
- —Migrate in slices the business understands: one site, one department, one service line.
- —Agree the rollback before the go-live, in writing, with a time limit.
- —Reconcile counts and money after every slice, not at the end.
- —Keep the old system readable for as long as your retention rules require.
A migration without a rehearsed rollback is not a plan, it is a hope with a date on it.
If you are carrying a system nobody wants to touch, the first piece of work is not a rebuild. It is a map: what depends on it, what data has to survive, and what a safe first slice looks like.