When should I stop or roll back a server migration?
Define rollback criteria before migration begins, including who decides and how current data will be protected. A rollback is straightforward only while the old environment remains a valid source of truth. Once the new system accepts writes, returning traffic may require data reconciliation.
Before you start
- The migration runbook, acceptance tests and owners of application and database decisions.
Instructions
1. Set measurable stop conditions
Identify unacceptable error rates, missing critical data, failed authentication and performance limits. Define how long the team can investigate before the window closes. Include inability to verify consistency or recovery access as a reason to stop before exposing the target to customers.
2. Define the data boundary
Record which system owns writes before, during and after cutover. Specify the last point at which changing traffic back remains safe and the procedure if post-cutover transactions exist. Keep the old system controlled so it cannot silently accept competing orders, uploads or jobs.
3. Prepare and rehearse the decision
Record previous endpoint values, required service states and the validation sequence for either direction. Ensure the decision maker can obtain current evidence and communicate the outcome. If forward repair is safer than reversal after a data transition, document that option and the conditions under which it applies.
Check the result
- The team can identify the decision deadline and the current authoritative data source.
- The chosen reversal or forward-recovery path preserves accepted transactions.
Troubleshooting
- The new service fails after receiving customer writes
- Control further writes and assess the reconciliation requirement before returning traffic. A DNS reversal alone does not transfer the new transactions to the old database.
Official references
Use the documentation for your installed version when a flag, service name or platform feature differs.