On this page
A migration fails when the cutover is the first time anyone runs the plan. The weekend outage is usually a substitute for a rehearsal that never happened.
We treat cutover as a short, timed change on top of weeks of parallel running. The new environment is already serving a copy of traffic, or it is ready to, before DNS moves.
Build the target before you announce a date
Stand up the landing zone first: accounts or subscriptions, identity, logging, and the network paths the application actually needs. Application teams should deploy into that landing zone the same way they will after go-live. A one-off server built by hand will drift the week after launch.
Data moves twice. The first copy is the bulk load. The second is the delta during the rehearsal. If you cannot name the delta tool and the lag it leaves, you do not have a cutover window yet. You have a wish.
Rehearse the rollback
Rollback is a procedure, not a mood. Write the steps, including who is allowed to call it and how long it takes to return users to the old stack. Practice it once on the rehearsal. A rollback that has never been timed is not a rollback.
During the live window we watch four things:
- Error rate against the week before
- Sign-in and the one transaction that makes you money
- Replication lag, if any data is still catching up
- The clock. A window that slips needs a decision, not more optimism.
After the DNS change
Leave the old environment in place, read-only, until the new one has a clean business day. Decommission is a separate change. Mixing it into cutover night is how backups disappear.
If you are planning a move and want a dated runbook rather than a slide, start with a discovery call.
