Why you need a rollback plan
A rollback plan is a procedure written in advance for cases where a migration goes wrong: the site does not load, the database is corrupted, or performance on the new server is lower than expected. Without a ready plan, the rollback decision gets made in a panic, wasting time figuring out what to restore and in what order.
Write the plan before the migration starts, not after the first error. It should record the rollback points, the decision criteria, and the step-by-step commands for reverting.
What to record before starting the migration
Before migrating, save a snapshot of the old server's state — it remains the reference point against which the new server is checked:
mysqldump -u root -p --all-databases > /backup/before_migration_2026_09_29.sql
tar czf /backup/files_before_migration.tar.gz /var/www
dig +short NS example.com > /backup/dns_before_migration.txt
Record the current TTL values of the DNS records and the current software versions (PHP, MySQL, the web server) — this data will be needed if the rollback has to happen a week after the move.
Rollback points: DNS, database, files
Define three independent points, each of which can be rolled back separately:
| Rollback point | What gets restored | Rollback time |
|---|---|---|
| DNS | A records pointing to the old server | 5 minutes to the TTL |
| Database | dump taken before the migration | 10-30 minutes |
| Files | archive taken before the transfer | 10-60 minutes |
Keep the old server running and unchanged for at least 7 days after the switch — this is the last rollback point if a problem surfaces later. The general approach to managing DNS during a move is covered in the article on switching hosting without downtime.
Criteria for deciding on a rollback
Write down in advance the conditions under which a rollback is mandatory, not just an option:
- The site returns 500 errors on more than 5% of requests for 15 minutes.
- Record counts in key database tables differ by more than 1%.
- Critical functionality (payments, login) is down for more than 30 minutes.
- Page performance drops by more than 2x compared to the old server.
Step-by-step rollback
The sequence of actions once a rollback decision is made:
# 1. Point the DNS records back to the old server
# 2. Confirm the old server still accepts requests
curl -I https://old-server-ip -H "Host: example.com"
# 3. Restore the database from the dump if the new server had received writes
mysql -u root -p example_db < /backup/before_migration_2026_09_29.sql
# 4. Notify users about the temporary unavailability of certain features
If data changed on the new server after the switch, sync the difference manually before rolling back — otherwise users will lose orders or comments created after the move.
Testing the rollback plan in advance
Test the plan in a staging environment before the real migration: deploy a copy of the site, perform the transfer, and then roll it back using the written plan. Measure the actual rollback time — it must fit within the acceptable downtime agreed with the site owner.
Summary: rollback readiness checklist
- Take a database dump and a file archive right before the migration.
- Record the current NS records and TTL before making changes.
- Define three rollback points: DNS, database, files.
- Write down numeric criteria that make a rollback mandatory.
- Test the rollback plan on a copy of the site in advance.
After a successful switch, whether or not a rollback happened, go through the general post-migration checklist, and for the database transfer itself use the MySQL database migration guide.