![Migrate WordPress Hosting With Zero Downtime [2026]](/images/blog/migrate-wordpress-hosting-with-zero-downtime-2026.jpg)
Most WordPress migrations fail at the DNS flip. You sync the files, import the database, update the name servers—and then watch five hours of white screens, mixed content warnings, and half-cached pages until propagation settles. The fix is a specific order of operations that keeps the old site serving traffic right up until the instant the new one is ready.
Why migrations break
Three things cause visitor-facing downtime during a host change. First: flipping DNS before the new host is fully configured. Requests land on a server that hasn't finished importing the database or still has placeholder Apache vhosts. Second: lowering DNS TTL too late. If your A record has a 24-hour TTL and you change it five minutes before the migration, recursive resolvers will cache the old IP for another day. Third: forgetting that WordPress hardcodes the site URL in dozens of database rows, so a quick search-replace that misses serialized arrays breaks widgets, images, and anything that stores JSON.
I've handled migrations where the site was unreachable for six hours because the new host's MySQL import timed out and no one tested the database before changing DNS. Check every step twice.
Pre-migration prep on the old host
Before you touch the new server, do three things on the current one.
Lower DNS TTL to five minutes
Log into your domain registrar or DNS provider. Find the A record pointing to your old server's IP. Change the TTL from 86400 (24 hours) to 300 (five minutes). Wait at least one full old-TTL cycle before you proceed—if it was 24 hours, wait 24 hours. This ensures that when you later point the A record to the new IP, resolvers pick up the change in minutes instead of days.
Take a final backup
Install a plugin like UpdraftPlus or use cPanel's backup wizard to grab a snapshot of files and database. Download it to your local machine. You want a rollback option if the new host mangles the import or you discover a compatibility issue mid-migration. I keep two copies: one on my laptop, one in a Dropbox folder, because Murphy's law applies double to production moves.
Inventory active plugins and PHP version
List every active plugin and note the current PHP version (in wp-admin under Tools → Site Health, or run php -v via SSH). Check the new host's PHP version. If the old site runs 7.4 and the new one defaults to 8.2, certain plugins will fatal-error the moment you import. Update plugins on the old host first, or plan to disable incompatible ones before the move.
Set up the new host in parallel
Now you configure the destination server while the old site continues serving live traffic.
Create the cPanel account or vhost
If the new host is cPanel, create the account but do not point DNS yet. If it's a VPS, configure the Apache or Nginx vhost with a ServerName matching your domain, but leave DNS alone. The goal is to have a fully working environment reachable by IP or a temporary hosts-file entry, invisible to the public.
Copy files via rsync or FTP
The cleanest method is rsync over SSH if both servers allow it:
rsync -avz -e ssh old_user@old_ip:/home/old_user/public_html/ /home/new_user/public_html/
That syncs the entire WordPress directory—core files, wp-content, .htaccess, everything. If SSH isn't available, download a zip from the old host's file manager and upload it to the new one, then extract. Either way, preserve file ownership and permissions. On cPanel, run:
chown -R new_user:new_user /home/new_user/public_html
find /home/new_user/public_html -type d -exec chmod 755 {} \;
find /home/new_user/public_html -type f -exec chmod 644 {} \;
Wrong ownership triggers permission-denied errors when WordPress tries to upload media or write to wp-config.php.
Export and import the database
On the old host, open phpMyAdmin, select the WordPress database, click Export, and choose "Custom" to enable compression (gzip). Download the .sql.gz file. On the new host, create a fresh database and user in cPanel or via command line:
mysql -u root -p
CREATE DATABASE new_wp_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'new_wp_user'@'localhost' IDENTIFIED BY 'strong_password';
GRANT ALL PRIVILEGES ON new_wp_db.* TO 'new_wp_user'@'localhost';
FLUSH PRIVILEGES;
Import the dump:
zcat backup.sql.gz | mysql -u new_wp_user -p new_wp_db
Or upload the .sql.gz through phpMyAdmin's Import tab. Verify row counts match the old database—select a large table like wp_posts and compare.
Update wp-config.php
Edit wp-config.php on the new host and change the database credentials:
define( 'DB_NAME', 'new_wp_db' );
define( 'DB_USER', 'new_wp_user' );
define( 'DB_PASSWORD', 'strong_password' );
define( 'DB_HOST', 'localhost' );
Some hosts use a remote MySQL server; replace localhost with the hostname provided in cPanel or your hosting panel.
Search-replace the site URL
WordPress stores the home and site URL in a dozen places: wp_options, post content, post meta, widget settings. A naive find-and-replace breaks serialized data. Use WP-CLI if available:
wp search-replace 'http://oldsite.com' 'http://newsite.com' --all-tables --precise
If WP-CLI isn't installed, download the Better Search Replace plugin, upload it to the new host's wp-content/plugins, activate it via direct database edit (set active_plugins in wp_options), then run the search-replace from wp-admin. Do not use phpMyAdmin's find-and-replace on serialized columns—it corrupts array lengths and kills widgets.
Test on the new host without changing DNS
This is the step most guides skip, and it's why migrations break.
Modify your local hosts file
On your workstation, edit the hosts file to point your domain to the new server's IP. On Linux/Mac:
sudo nano /etc/hosts
On Windows, open C:\Windows\System32\drivers\etc\hosts as Administrator. Add:
192.0.2.50 yoursite.com www.yoursite.com
Replace 192.0.2.50 with the new host's IP. Save and flush DNS:
# Linux/Mac
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder # macOS
sudo systemd-resolve --flush-caches # Linux
# Windows (cmd as Admin)
ipconfig /flushdns
Now when you visit yoursite.com in a browser, it resolves to the new server while the rest of the world still sees the old one.
Walk through the site
Log into wp-admin. Check the dashboard, edit a post, upload an image, preview the front end. Click through five high-traffic pages. Verify images load, forms submit, and plugins function. Open the browser console (F12) and confirm no 404s or mixed-content warnings. If you see broken images, the search-replace missed an absolute URL somewhere—run it again with and without www.
Test on mobile and desktop. If the site uses a page builder (Elementor, Divi), open a page in the builder and ensure drag-and-drop works. I once migrated a site where the builder's CSS failed to load because the new host's mod_security blocked certain POST requests; better to catch that now than after DNS flips.
Perform a final sync
Your test might take a few hours. Meanwhile, users are still uploading media and publishing posts on the old host. You need one last incremental sync.
Sync recent files
Re-run rsync to grab new uploads:
rsync -avz --update -e ssh old_user@old_ip:/home/old_user/public_html/wp-content/uploads/ /home/new_user/public_html/wp-content/uploads/
The --update flag skips files that haven't changed.
Export and re-import the database
If the site is active, a full re-import risks losing changes made on the new host during testing. Instead, export only changed tables or use a plugin like WP Migrate DB to push incremental changes. For low-traffic sites, I usually just re-export the whole database and re-import—takes two minutes and guarantees consistency.
If you made content edits on the new host during testing (you shouldn't, but it happens), note those posts and manually copy them over after the import.
Flip DNS
Now the new host is live, tested, and synced. Time to redirect the world.
Update the A record
Log into your DNS provider. Change the A record for @ and www to point to the new host's IP. If you lowered TTL earlier, this change propagates in five minutes. If you forgot, expect a few hours of mixed traffic—some users hitting old, some hitting new.
Don't delete the old A record and add a new one; edit the existing one in place. Some DNS providers treat delete+add as two separate transactions with separate TTLs.
Monitor both servers
For the next 30 minutes, watch access logs on both old and new hosts. On cPanel:
tail -f /home/old_user/access-logs/yoursite.com
tail -f /home/new_user/access-logs/yoursite.com
You'll see traffic gradually shift from old to new. When the old log stops scrolling, propagation is mostly complete. Check from a different network (mobile data, a VPS in another region) to confirm the new IP resolves.
Test again from a clean browser
Clear your local hosts file (remove the line you added earlier), flush DNS, open an incognito window, and visit the site. If it loads correctly, you're done. If you see the old host or a blank page, check that the A record change saved and that you're not hitting a cached DNS response.
Post-migration cleanup
Once DNS has fully propagated and traffic is stable on the new host, do three things.
Raise DNS TTL back up
Change the A record TTL from 300 back to 3600 or 86400. No reason to force recursive resolvers to re-query every five minutes forever.
Leave the old host live for 48 hours
Don't cancel the old hosting account immediately. A few users might have stale DNS cache or ancient ISP resolvers. Let the old server serve those stragglers. After two days, if logs show zero traffic, it's safe to terminate.
Update external services
If you use a CDN, email delivery service, or external backup tool, log in and update the server IP or SFTP credentials to match the new host. Otherwise you'll get mysterious backup failures or CDN origin errors a week later.
What if something breaks after the flip?
If the site goes down post-migration, you have a rollback path. Change the A record back to the old IP—since you left the old host running, traffic returns to the original server within minutes. Fix the issue on the new host without pressure, test again via hosts file, then re-flip DNS when ready.
Common breaks: incorrect database prefix in wp-config (you copied the config from a different site), file permissions locking wp-admin out, or a plugin that hardcodes the old server's IP (I've seen this with certain caching plugins). Check error logs first:
tail -f /home/new_user/public_html/wp-content/debug.log
tail -f /usr/local/apache/logs/error_log
Enable WordPress debug mode if it isn't already:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
That writes PHP errors to wp-content/debug.log without showing them to visitors.
FAQ
Do I need to put the site in maintenance mode during migration?
No. If you follow the parallel-setup method, the old site stays live until the DNS flip. Visitors never see downtime.
Can I change the domain name at the same time as changing hosts?
Yes, but do the search-replace with the new domain before you flip DNS. Test thoroughly via hosts file because reversing a domain change is messy.
What if my new host's PHP version is newer and breaks the site?
In cPanel, use MultiPHP Manager to set the domain to the same PHP version as the old host. Upgrade PHP after the migration, one minor version at a time, testing between each bump.
How long should I keep the old hosting account active?
48 hours minimum. If the site has international traffic, consider 72 hours to catch slow-propagating DNS.
Will email break during migration?
If MX records point to the old server's hostname, update them to point to the new server's hostname or an external provider (Google Workspace, etc.) before you flip the A record. Otherwise incoming mail lands on the old server after migration.
Keep the old host live until DNS clears
The single biggest mistake is canceling the old hosting account the moment you change DNS. Propagation is never instant. A five-minute TTL means resolvers should refresh in five minutes, but some don't. Some corporate firewalls cache for hours regardless of TTL. Some mobile carriers run ancient recursive resolvers that ignore TTL entirely. Leaving the old server active for two days costs you a few extra dollars and saves you from emergency rollbacks at midnight. When logs on the old server show zero hits for 24 hours straight, it's safe to pull the plug.