The Website Migration Checklist: Move Hosts Without Downtime or Data Loss
Migrations go wrong more often than they should. The problems are almost always predictable and preventable with the right sequence. Here is the complete checklist, with every step in the correct order.
Hosting migrations have a reputation for catastrophe. Sites down for hours. Email broken for days. Databases corrupted. Google confused about which version to index. Almost all of these problems are predictable, and almost all are preventable with proper sequencing. After dozens of migrations, here is the complete checklist.
Phase 1: Inventory and Preparation (1–2 Weeks Before)
The biggest migration mistakes happen because this phase gets skipped. Don't.
Document your current setup:
- Current host, plan name, account email and login
- PHP version and any non-standard extensions required
- MySQL/PostgreSQL version and all database names
- All domain names on the account
- All email accounts and their configurations
- All cron jobs and schedules
- Any custom server config, SSL certificates, virtual host rules
Lower your DNS TTLs now. Reduce all record TTLs to 300 seconds at least 24–48 hours before migration day. This ensures DNS changes propagate in minutes rather than hours when you finally cut over.
🔍 DNS Lookup Tool
Check your current TTL values before lowering them for migration.
Phase 2: Set Up and Test the New Server (2–5 Days Before)
Never touch DNS until the new server is completely configured and tested in parallel with the live site.
- Provision the new server with matching PHP version and extensions
- Export a fresh database backup from the current host
- Download all website files via SFTP or your control panel
- Upload files to the new server
- Import the database on the new server
- Update config files (wp-config.php, .env) with new database credentials
- Install and configure an SSL certificate for your domain on the new host
Phase 3: Test With /etc/hosts Override
Before changing DNS, preview the site on the new server under your actual domain by editing your local /etc/hosts file to point the domain at the new IP. This lets you test in exact production conditions without affecting real visitors.
# Mac/Linux: /etc/hosts — Windows: C:\Windows\System32\drivers\etc\hosts
203.0.113.42 example.com www.example.com
Replace the IP with your new server's. Remove these lines immediately after testing.
Phase 4: The Cutover
Do this during your lowest-traffic window — early morning in your primary audience's timezone.
- Take a final database backup from the old server immediately before cutover
- Update the A record to the new server IP
- If changing nameservers, update at your domain registrar
- Start monitoring from multiple devices and locations immediately
- Use the propagation checker to watch the change spread globally
🌍 DNS Propagation Checker
Watch your DNS change spread across global servers in real time during cutover.
Phase 5: Post-Migration Verification
- Verify SSL is working and there are no mixed content warnings
- Confirm all redirects are in place (www → non-www or vice versa)
- Submit updated sitemap to Google Search Console
- Monitor uptime for the first 48 hours
- Test email — send and receive both directions
- Verify all cron jobs are running on the new server
- Keep old hosting active for 2–4 weeks as a safety net
The Email Problem Nobody Warns You About
Email is the single most commonly forgotten component of hosting migrations. If your MX records point to your current host's mail servers, you need to migrate email accounts too — or point MX records to an external provider (Google Workspace, Microsoft 365) before migrating web hosting.
If the old server stops handling mail and the new one isn't ready, email sent to your domain during that window bounces and is lost permanently. There is no automatic fallback.
📦 Migration Checklist Generator
Generate a personalised migration checklist for your specific setup and platform.