To complete a website migration without downtime, lower your DNS TTL to 300 seconds 48 hours in advance, deploy your files and database to the new server, test via a local hosts file, and update your DNS records. Visitors seamlessly shift to the new host with zero dropped connections or lost transactions.
The Strategic Framework / Why Most Get This Wrong
Most failed site migrations boil down to one rookie mistake: treating server migration like moving houses in the physical world. In a physical move, you pack your boxes, load the truck, shut the old door, and unpack at the new place. If you do that with a website, your visitors hit connection timeouts, partial DNS resolution errors, and broken database sessions.
Web traffic doesn’t stop just because you flipped an IP address. DNS caching exists across thousands of recursive resolvers worldwide. When you update an A record at your registrar, some ISPs cache the old IP address for 24 to 72 hours if you didn’t adjust your TTL (Time To Live). During that window, some users hit your old server while others reach the new one.
If you run an e-commerce store, a membership site, or an active blog with comments, this split creates a split-brain database disaster. An order processed on the old server never shows up on the new server. Our goal is simple: ensure both environments stay synced, traffic redirects transparently, and the cutover happens invisibly.
Step-by-Step Implementation Blueprint
Step 1: Lower DNS TTL (The 48-Hour Buffer)
Before touching a single file, log into your DNS management provider (Cloudflare, Route 53, or your registrar). Locate your primary root and subdomain A records.
Check the current TTL value. It is usually set to 86400 (24 hours) or 43200 (12 hours). Change this value to 300 seconds (5 minutes). Save the records and wait a full 48 hours before doing anything else. This guarantees that all upstream ISP resolver caches expire, ensuring that when you finally switch servers later, the new IP takes effect in under five minutes globally.
Step 2: Replicate File Assets and Configs
Next, package your filesystem. Avoid clunky web-based file managers that time out on large archives. Use SSH and rsync or native compressed tarballs instead:
tar -czf site_backup.tar.gz /var/www/html/public/Transfer the compressed archive directly across servers via SCP:
scp site_backup.tar.gz user@new-server-ip:/var/www/html/Unpack the contents and check file permissions. Ensure your web server user (such as www-data or nginx) retains ownership:
chown -R www-data:www-data /var/www/html/public/Step 3: Database Dump and Strict Delta Sync
Export your database using mysqldump with single-transaction flags to prevent table locks:
mysqldump -u root -p --single-transaction --quick db_name > db_backup.sqlImport the database on the destination host:
mysql -u db_user -p new_db_name < db_backup.sqlUpdate your application configuration file (such as wp-config.php or .env) on the new host to reference the new database credentials and local user accounts.
Step 4: Stage and Validate via Local Hosts File
Never switch your public DNS without verifying the target installation. You can bypass public DNS entirely on your local machine by modifying your operating system hosts file.
On macOS or Linux, edit /etc/hosts. On Windows, edit C:\Windows\System32\drivers\etc\hosts as Administrator. Add a line pointing your live domain to the new server’s IP address:
198.51.100.45 yourdomain.com www.yourdomain.comClear your browser cache, open your browser, and navigate to your site. You are now browsing the new host. Test login flows, user registration, cart checkout, and SSL certificate binding. If you want to check server response speeds before launch, review our blueprint on How to Reduce TTFB Under 200ms: Practical Server Blueprint to audit your caching and PHP worker configs before flipping live traffic.
Step 5: The Live Cutover and Temporary Reverse Proxy
Once verified, remove the line from your local hosts file. For dynamic websites like WooCommerce, place the old site into temporary read-only maintenance mode or set up a MySQL replication link. Alternatively, configure Nginx on the old server to proxy all incoming requests to the new server IP during the transition:
server {
listen 80;
listen 443 ssl;
server_name yourdomain.com;
location / {
proxy_pass https://198.51.100.45;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}Update your DNS A and AAAA records to point to the new server IP. Because your TTL was lowered to 300 seconds, traffic moves over quickly. Even if an isolated resolver lags, the old server simply forwards requests to the new host without dropping transactions.
Practical Checklist / Cheat Sheet Table
Keep this operational checklist handy during your next maintenance window:
| Stage | Critical Action | Verification Method |
|---|---|---|
| T-48 Hours | Lower primary DNS TTL to 300s | Run dig yourdomain.com +nocmd +noall +answer |
| T-4 Hours | Migrate static files and base database | Verify disk usage with du -sh |
| T-1 Hour | Test new server with local hosts file | Inspect response headers and SSL validity |
| T-0 Minutes | Execute delta DB dump and switch DNS A record | Monitor global propagation via DNSchecker |
| T+24 Hours | Restore standard TTL (86400s) and retire old host | Confirm old access logs show zero requests |
Recommended Tools & Resources
- Cloudflare DNS: Free, ultra-fast DNS with instantaneous TTL propagation and built-in proxy controls.
- WP Migrate (formerly WP Migrate DB Pro): Perfect WordPress database migration utility with automated serialized data search and replace.
- Duplicator Pro: A trusted backup and site cloner when migrating complex WordPress installations without manual CLI commands. If you are setting up WordPress on a modern stack, consult our guide on How to Set Up and Optimize Your WordPress Website with Hostinger: A Complete Guide for optimal server templates.
- DNSChecker.org: Global DNS propagation checker to verify real-time status across 30+ regional nameservers.
