WordPress Server Migration Without Downtime: Full Guide

Step Process to Migrate WordPress Without Downtime

1. Pack files and database from the current server.
2. Deploy the packed data to the new server and configure it.
3. Verify the new server before switching DNS.
4. Rehearse with a hosts file entry on your local machine.
5. Switch DNS and run post-switch checks.
6. Roll back immediately if any check fails.

Packing Files and Database

Start on the live server. You need a complete, consistent copy of /var/www/example.com/ and the WordPress database. Use wp db export rather than raw mysqldump when possible because WP-CLI (v2.11 in 2026) handles table prefixes and charset correctly. Run this from the site root:

cd /var/www/example.com nwp db export /tmp/example_prod.sql --add-drop-table
 tar -czf /tmp/example_files.tar.gz -C /var/www/example.com .

Do not use cp -r over the network for large sites; use rsync to the new host so you can re-run it later to catch changes:

rsync -avz --delete -e 'ssh -p 22' /var/www/example.com/ user@new-server:/var/www/example.com/
scp /tmp/example_prod.sql user@new-server:/tmp/

Pitfall: if you pack files and database at different times, new comments or orders created in between are lost. Lower the DNS TTL to 60 seconds 24 hours before you start, then do the final rsync and wp db export together in one maintenance window of seconds. Verify the archive: run tar -tzf /tmp/example_files.tar.gz | wc -l and compare the count with find . -type f | wc -l on the source.

Verifying Before Switching DNS

On the new server, import the database and set the site URL to the temporary internal hostname so you can test without DNS. Use WP-CLI to replace URLs only after you decide the test hostname:

cd /var/www/example.com
wp config set DB_NAME example_db
wp config set DB_USER example_user
wp config set DB_PASSWORD 'secure_pass_2026'
wp db import /tmp/example_prod.sql
wp search-replace 'https://example.com' 'https://new.example.com' --dry-run

Review the dry-run row count, then run without --dry-run. Now check PHP version compatibility; as of 2026 many sites run PHP 8.2 or 8.3. Confirm with wp cli info and php -v. Test that the site responds by curling the local hostname:

curl -I https://new.example.com --resolve new.example.com:443:127.0.0.1

Pitfall: forgetting wp rewrite flush after import leaves permalinks broken. Run wp rewrite flush --hard and visit /wp-admin/options-permalink.php once. Verify the checksums match the source with wp core verify-checksums and that all plugins are active via wp plugin list. If you use object caching such as Redis, ensure wp redis status reports connected. This verification step is where you prove the new server is a mirror before anyone else sees it.

Hosts File Rehearsal

Before DNS moves, edit your own machine’s hosts file to map the real domain to the new server IP. On Linux or macOS edit /etc/hosts; on Windows edit C:WindowsSystem32driversetchosts. Add:

203.0.113.50 example.com www.example.com

Flush DNS with sudo dscacheutil -flushcache (macOS) or sudo systemd-resolve --flush-caches (Linux). Now browse the production domain and you are hitting the new server only. Log in to /wp-admin, publish a test post, submit a contact form, and complete a test order if WooCommerce is active. Check /wp-content/debug.log for fatal errors. Because WordPress Site Migration rehearsal happens on your machine, real users still hit the old server, so there is no downtime. Pitfall: browser DNS caching can ignore hosts changes; use a private window or curl --resolve as shown earlier. When the rehearsal passes, remove the hosts entry.

Post-Switch Checks and Rollback

Lower TTL to 60s a day earlier, then change DNS A record to the new server IP. Within minutes, traffic arrives at the new stack. Immediately run these checks: wp core verify-checksums, wp db check, wp option get siteurl, and confirm SSL with openssl s_client -connect example.com:443. Watch logs with tail -f /var/log/nginx/error.log. Test checkout, login, and cron via wp cron test; if you rely on system cron, see Why WP-Cron Fails and What to Use Instead to confirm the scheduler is external. If anything is broken, roll back: revert DNS to the old IP. Since TTL is 60s, most users reconnect to the old server within a minute. Keep the old server running untouched for 48 hours. The rollback is safe because you never dropped the old database; you only copied it. After 48 hours of clean metrics, decommission the old node.

Action Checklist

• Pack files with rsync and database with wp db export in one final sync.
• Import, search-replace, and flush rewrites on the new server.
• Rehearse with hosts file and verify forms, admin, and SSL.
• Switch DNS with 60s TTL and monitor logs for 48 hours.
• Roll back DNS to old IP if any post-switch check fails.

Frequently asked questions

How long does DNS propagation take in 2026?

With a 60-second TTL set beforehand, most resolvers update within one to two minutes. Full global propagation can still take up to 48 hours on stubborn ISP caches, which is why you keep the old server live as rollback.

Can I use this method for WooCommerce stores?

Yes. The hosts file rehearsal lets you place a real test order before DNS switch. Just ensure you put the store in maintenance mode during the few seconds of final sync so no live transaction is written to the old database after export.

What if the new server has a different PHP version?

Test compatibility on the new server during verification with php -v and wp plugin list. If you target PHP 8.2, read the upgrade notes and run unit tests before the rehearsal, never after DNS switch.

Need a team to execute this for you? Our engineers handle zero-downtime moves every week. See our full WordPress services and let us migrate your site safely today.

“, “faq”: [ { “question”: “How long does DNS propagation take in 2026?”, “answer”: “With a 60-second TTL set beforehand, most resolvers update within one to two minutes. Full global propagation can still take up to 48 hours on stubborn ISP caches, which is why you keep the old server live as rollback.” }, { “question”: “Can I use this method for WooCommerce stores?”, “answer”: “Yes. The hosts file rehearsal lets you place a real test order before DNS switch. Just ensure you put the store in maintenance mode during the few seconds of final sync so no live transaction is written to the old database after export.” }, { “question”: “What if the new server has a different PHP version?”, “answer”: “Test compatibility on the new server during verification with php -v and wp plugin list. If you target PHP 8.2, read the upgrade notes and run unit tests before the rehearsal, never after DNS switch.” } ], “cover”: “A modern flat technical illustration of two server racks connected by glowing data streams with a WordPress dashboard panel floating between them, blue and teal palette, clean isometric style, no text or logos.

References & further reading

• WordPress Developer Documentation
• WordPress Theme Handbook
• WordPress Plugin Handbook