Most discussion of a migration focuses on the destination: the new platform, the cleaner architecture, the features the old system could not support. That is the easy part to plan for. The hard part is the few hours when both systems are partly true at once, and the question is whether anyone notices.
A system with no users can be migrated however is convenient: export, transform, import, switch. A system with live traffic cannot. Users are placing orders, services are writing records, and sessions are open at the exact moment you need the data frozen and moved. The outage risk lives entirely in that window.
The cutover is the project
It is common to spend weeks rebuilding on a new platform and treat the switch itself as an afterthought, a late-night job that “just” repoints traffic. That ordering is backwards. The rebuild is predictable work. The cutover is where data is lost, where the new system meets production load for the first time, and where rolling back is either possible or it is not.
Plan a migration from the cutover outward: decide how the switch will happen and how you will reverse it, then build everything else to serve that moment.
Run both systems before you commit
The safest cutovers are the ones that happened gradually before anyone announced them.
- Dual-run where you can: have the new system process real traffic in parallel, reading the same inputs and writing to its own store, while the old system stays authoritative. Any difference between the two outputs is a defect found before it matters.
- Backfill, then reconcile. Copy historical data into the new system early, then run an automated comparison that proves the two stores agree. A migration that cannot be reconciled cannot be trusted, however clean the new schema looks.
- Keep early schema changes additive. Add new structures alongside the old rather than replacing them in place; an expand-then-contract approach lets the old and new code paths coexist, so nothing breaks the instant a column changes shape.
Keep a rollback you have actually used
A rollback plan that has never been executed is a hope, not a plan. Before the real cutover, the reverse path, switching authority back to the original system with no data loss, should have been run at least once on a staging copy. If returning to the old system would itself cause an outage, the migration is not ready.
Feature flags and a routing layer that can move traffic in small increments turn the cutover from a single irreversible event into a dial. A fraction of traffic moves first, you watch how the system responds, and the dial moves further only once the data reconciles and the error rate holds.
Cut over deliberately, then verify
- Choose the quietest window the business has. Lower traffic means a smaller blast radius and more room to react.
- Move a slice before the whole. Route a small percentage of traffic to the new system and confirm its outputs match the old one before widening.
- Verify against reality, not the deploy log. A successful deployment is not a successful migration. Check that records reconcile, that the numbers users see are unchanged, and that the workflows people actually run still complete.
- Hold the old system in reserve. Keep it ready to take authority back until the new system has proven itself under a full cycle of real load, not just the first hour.
A migration done this way is undramatic by design. There is no maintenance page, no held breath, no single moment everything depends on. The work that makes that possible is mostly invisible, which is exactly why it tends to be cut first.
When a migration is bundled into rescuing a system that is already struggling, the order of operations matters even more, which is the subject of the early signs a software project is in trouble. When an outage is not an option, it is the kind of work our project rescue practice is built around.
