How I Migrated 50+ Sites to New Servers With Zero Downtime

Why Most Migrations Fail

Before we dive into the checklist, let's talk about the three reasons migrations usually go sideways:

1. DNS Propagation Surprise

You update DNS at 2 PM. Half your users see the old server until midnight. Some see error 500s because the database isn't synced. It's chaos.

2. "It Works On My Machine"

The new server looks perfect when you test it. Then you switch DNS and discover the production database credentials are wrong, SSL isn't configured, or PHP version is different. Site goes down.

3. The Rollback Panic

Something breaks. You try to roll back. But DNS changes take hours. Your old server is already shut down. You're stuck in limbo with a broken site.

Sound familiar? Good news: all of these are preventable with proper planning.

The Zero-Downtime Migration Checklist

📋 Time commitment:

For a typical site: 3-4 hours of work spread over 2-3 days. Yes, days. Rushing is how you break things.

Phase 1: Preparation (Day 1)

Lower Your TTL to 300 Seconds

This is THE most important step. Go to your DNS provider right now and reduce TTL to 5 minutes (300 seconds) for all your A records.

Before:

example.com A 86400 123.45.67.89

After:

example.com A 300 123.45.67.89

Why? DNS changes respect the OLD TTL value. If your TTL was 24 hours (86400), changes can take 24 hours to propagate. At 5 minutes, most users will see the new server within minutes of switching.

Document Everything

Create a migration document with:

Current server IP and new server IP
All domain names and subdomains
Database credentials (old and new)
Email server settings
SSL certificate details
Cron jobs and scheduled tasks
Environment variables
External API keys and integrations

Create Full Backups

Backup everything from the old server:

# Files
tar -czf site-backup-$(date +%Y%m%d).tar.gz /var/www/html

# Database
mysqldump -u user -p database > db-backup-$(date +%Y%m%d).sql

# Download to local machine
scp user@oldserver:/path/to/backups/* ./backups/

Store backups locally AND in cloud storage. I've seen servers fail mid-migration. Having local copies saved me twice.

Phase 2: New Server Setup (Day 1-2)

Match the Environment Exactly

Install the EXACT same versions of everything:

PHP/Python/Node version
Database version (MySQL 5.7 vs 8.0 matters!)
Web server (Apache/Nginx)
SSL/TLS version
OS version if possible

💡 Pro tip:

Run php -v, mysql --version, etc. on the old server. Copy the output. Install those exact versions on the new server.

Transfer Files and Database

Upload your backups to the new server:

# Upload files
scp site-backup.tar.gz user@newserver:/var/www/
ssh user@newserver 'cd /var/www && tar -xzf site-backup.tar.gz'

# Import database
scp db-backup.sql user@newserver:/tmp/
ssh user@newserver 'mysql -u user -p database < /tmp/db-backup.sql'

Configure SSL Certificate

Set up SSL BEFORE switching DNS:

# For Let's Encrypt with Nginx
sudo certbot --nginx -d example.com -d www.example.com

# Test SSL
curl -I https://NEW-SERVER-IP -H 'Host: example.com' --resolve example.com:443:NEW-SERVER-IP

Some SSL providers need domain validation. Set up a temporary DNS override in your hosts file for testing.

Test With Host Preview

Here's where most people mess up. You need to test the new server WITHOUT changing DNS. Use our Host Preview tool:

Enter your domain: example.com
Enter new server IP: 45.67.89.123
Get a preview URL like: xyz123-example.avoidns.com
Test everything through that URL

✅ This is game-changing:

You're testing the actual new server with your actual domain name, but without affecting production. Find and fix issues before switching DNS.

Phase 3: Testing (Day 2)

The 20-Point Testing Checklist

Test these on the preview URL. Check off each one:

Homepage loads correctly
All internal links work
Images and assets load
Login functionality works
Forms submit correctly
Database queries work
File uploads work
Shopping cart/checkout (if applicable)
Email sending works
API integrations (payment, analytics, etc.)
SSL certificate valid
Redirects configured (www vs non-www)
robots.txt accessible
sitemap.xml accessible
Page load speed acceptable
Mobile responsive
Cron jobs configured
Log files writable
Cache working (if applicable)
Admin panel accessible

Phase 4: The Switch (Day 3)

Enable Read-Only Mode (Optional but Smart)

For 5-10 minutes during the switch, put the site in "maintenance mode" or make the database read-only. This prevents data loss if someone makes changes during DNS propagation.

Update DNS

Change your A record to point to the new server IP. With TTL at 300 seconds, most users will be on the new server within 5-10 minutes.

example.com A 300 45.67.89.123 (new IP)

Monitor Propagation

Use our DNS Propagation Checker to watch the change spread globally. Check every 5 minutes.

Most DNS servers will update within 10-15 minutes with a low TTL, but some stubborn ones can take an hour.

Keep Old Server Running

DO NOT shut down the old server yet! Keep it running for 24-48 hours minimum. Some DNS servers will take longer to update, and those users will still hit the old server.

⚠️ Common mistake:

Shutting down the old server immediately causes downtime for users whose DNS hasn't updated yet.

Phase 5: Post-Migration (Day 3-4)

Monitor Everything

For the first 24 hours, check:

Server logs for errors
Website uptime (use UptimeRobot or similar)
Google Analytics for traffic drops
Form submissions still working
Email delivery
SSL certificate status

Increase TTL Back Up

After 48 hours, when you're confident everything works, increase your TTL back to 3600 or 86400 to reduce DNS queries.

Decomission Old Server

After 72 hours of smooth operation:

Take final backup of old server
Download all logs for reference
Shut down old server
Keep backup for 30 days "just in case"

The "Oh Crap" Rollback Plan

Despite perfect planning, sometimes things go wrong. Here's how to roll back quickly:

Emergency Rollback Procedure

1. Change DNS back to old server IP immediately
2. With TTL at 300, most users roll back within minutes
3. Put up maintenance page on new server
4. Debug the issue without time pressure
5. Try again when fixed

This is why keeping the old server running and having low TTL is critical. You can roll back in minutes instead of hours.

Real Story: The WordPress Migration That Went Perfect

Last month, I migrated a high-traffic WordPress site (50,000 visitors/day) using this exact checklist. Here's what made it successful:

Day 1: Lowered TTL, took backups, set up new server
Day 2: Used Host Preview tool to test exhaustively. Found 3 issues (wrong PHP version, missing ImageMagick, broken permalink structure). Fixed them all before DNS switch.
Day 3 at 2 AM: Switched DNS during lowest traffic period. Monitored for 2 hours. Zero errors.
Day 4: Traffic graphs showed no dip. Page load times actually improved. Client didn't receive a single complaint.

Total downtime: 0 seconds. That's what proper planning gets you.

Your Migration Toolkit

These tools will make your migration smooth:

→ Host Preview Tool

Test new server before DNS switch

→ DNS Propagation Checker

Monitor DNS changes globally

→ SSL Certificate Checker

Verify SSL on new server

Final Thoughts

Server migrations don't have to be stressful. The secret is simple: test everything before switching DNS, keep both servers running during propagation, and don't rush.

I've used this checklist for 50+ migrations without a single minute of unplanned downtime. You can too. Take your time, follow the steps, and use the right tools.