Rollback Plan: What to Do If Migration Fails

Why You Need a Rollback Plan

Every migration carries a risk of failure. No matter how thoroughly you plan and test, unexpected problems can emerge. A rollback plan is the safety net that ensures you can return to your previous state within minutes instead of spending hours scrambling and troubleshooting.

The difference between a professional engineer and a beginner: the professional plans for failure before starting. This guide explains how to build a solid rollback plan for every scenario.

Rollback Plan Principles

1. Define Rollback Criteria in Advance

Do not wait until you are in the middle of a crisis to decide. Before migration, define exactly when you roll back:

Criterion	Threshold	Decision
Application unresponsive	More than 5 minutes	Immediate rollback
Repeated 500 errors	More than 10 per minute	Immediate rollback
Missing or corrupted data	Any amount	Immediate rollback
Noticeable slowness	3x slower than before	Investigate then decide
Payment gateway failure	Any failure	Immediate rollback
Email not sending	More than 30 minutes	Investigate then decide

2. Define Your Rollback Window

The rollback window is the period during which reverting is easy. After this window, rolling back becomes harder or impossible:

• First hour: Easy rollback — DNS has not fully propagated, data is nearly identical
• 1-24 hours: Possible rollback — but you may lose new data entered on the new server
• After 24 hours: Difficult rollback — data has diverged between servers
• After 72 hours: Near-impossible without data loss

3. Document Every Step

The rollback plan must be written in detail, step by step, so that anyone can execute it even if you are unavailable. Never rely on memory during moments of high pressure.

Building Your Rollback Plan: Step by Step

Step 1: Complete Backup Before Migration

1. Full database backup with timestamp
2. Full backup of application files and user uploads
3. Copy of server configurations (Nginx, PHP, MySQL configs)
4. Copy of current DNS records
5. Copy of cron jobs and scheduled tasks
6. Store everything in a third location (not the old or new server)

Step 2: Keep the Old Server Ready

Do not touch the old server after migration. Do not delete anything, do not stop anything. Keep it running as-is for at least 72 hours. This is your first and fastest fallback option.

• Application is running and responding to requests
• Database is running and current up to the switchover moment
• SSL certificate is still valid
• Old IP address is still reserved for you

Step 3: Quick Rollback via DNS

The simplest rollback method: revert the DNS record to the old IP address. If you lowered TTL to 300 seconds in advance, users return to the old server within 5 minutes.

Step 4: Handling New Data

The biggest challenge: after the switchover, users entered new data on the new server. If you roll back, this data is lost. Solutions:

• Reverse replication: Enable replication from new to old as well (dual-write)
• Export new data: Export only records created after the switchover and insert them manually
• Accept the loss: In some cases, losing one hour of data is less harmful than continued failure

Rollback Scenarios

Scenario 1: Application Not Working

1. Revert DNS to the old IP immediately
2. Verify the old server is responding
3. Analyze the failure cause on the new server
4. Fix the issue and retry later

Scenario 2: Poor Performance

1. Monitor for 30 minutes — it may be cold cache effects
2. If slowness persists: check database and web server configurations
3. If no improvement: revert DNS and analyze the problem

Scenario 3: Corrupted Data

1. Stop the application on the new server immediately (prevent further writes)
2. Revert DNS to the old server
3. Analyze the source of corruption
4. Restore from a verified backup

Testing Your Rollback Plan

An untested rollback plan is just wishful thinking. Before the actual migration:

• Execute a practice rollback: switch DNS and revert it, measure the time
• Confirm your backups are actually restorable
• Ensure every team member knows their role
• Establish an emergency communication channel

Rollback Plan Template

Here is a ready-to-use template you can copy and customize for your system:

Item	Details
Planned migration date	[Date and time]
Rollback window	[e.g., first 24 hours]
Old server IP	[IP address]
New server IP	[IP address]
Backup location	[Path/third server]
Execution lead	[Developer name]
Decision maker	[Manager name]
Emergency channel	[WhatsApp/Slack/Phone]

Rollback Steps (Execute in Order)

1. Stop the application on the new server: sudo systemctl stop nginx
2. Export new data if possible: mysqldump --where="created_at > 'YYYY-MM-DD HH:MM:SS'" db > new_data.sql
3. Revert the DNS A record to the old IP address
4. Confirm the old server is receiving traffic: monitor access.log
5. Notify the team that the rollback completed successfully
6. Analyze the failure cause and plan a second attempt

Rollback Planning with CLOUD

CLOUD (cloud.net.sa) provides free technical guidance sessions for clients' developers that include reviewing the rollback plan before any migration. We help you define appropriate rollback criteria for your system and ensure you have a solid safety net before you begin.

Never start a migration without a written and tested rollback plan. The minutes you spend planning save you hours of stress and chaos.

--- ### Get Started Want to try it yourself? Choose the right hosting plan or build your custom server with the specs you need.