Cutting over without cutting off

The most dangerous hour in any system replacement is the one where the old system is switched off.

Most failed deployments do not fail during the build. They fail on the Monday the business is asked to trust something it has not yet seen work.

Why big-bang cutovers fail

A single switch-over date concentrates every unknown into one day: data that did not migrate cleanly, a workflow nobody thought to mention, staff trained on a test system that looked different. When something breaks there is no way back, only a long afternoon.

Run both systems in parallel

The alternative is slower and much safer. The new system runs alongside the old one on real transactions. Work is recorded in both for an agreed period, and every day the outputs are compared: stock counts, invoice totals, patient registers, whatever the business actually depends on.

Parallel running costs extra effort for a few weeks. It is the cheapest insurance in the whole project.

Define matched before you start

Parallel running only works if everyone agrees in advance what a good day looks like. We write the acceptance checks down before go-live.

• Which reports must reconcile, and to what tolerance.
• How many consecutive clean days are required before cutover.
• Who signs off, by name.
• What triggers a rollback, and who decides.

Keep the way back open

Even after sign-off, the cutover should be reversible. The old system stays read-only for a defined period, data can still be exported from the new one, and the team knows who to call. Rollbacks are rarely needed. Knowing they exist is what lets people commit to the new system.

Train on real work

Training on a demo environment teaches people a demo. Staff learn fastest on their own transactions during the parallel period, with someone from the deployment team on the floor for the first days. The questions asked at the counter are the ones that reveal what the workflow map got wrong.