Moving a WordPress site between hosting providers is routine—until it isn't. One wrong step and your site goes dark, email stops flowing, or visitors land on a half-broken homepage. Most downtime isn't caused by bad luck. It's caused by predictable mistakes that every experienced engineer has seen a dozen times.
I've walked hundreds of site owners through migrations over the years. The problems are almost always the same. Here are the nine mistakes that cause the most trouble, and what to do instead.
1. Not testing the new server before you switch DNS
You upload everything to the new host, the files look right in cPanel, and the database imports without errors. So you update DNS and wait. Five minutes later visitors start reporting a broken site.
The mistake: assuming that because the migration steps succeeded, the site actually works. DNS changes are hard to reverse quickly—once visitors start getting routed to the new IP, you're committed.
Before you touch DNS, force your local machine to resolve the domain to the new server's IP. Add a line to your hosts file:
203.0.113.45 example.com www.example.com
Replace that IP with your new server's address. Now when you visit the site in your browser, you'll hit the new host while the rest of the world still sees the old one. Test everything: homepage, login, a few posts, contact forms, checkout if you run a shop.
Common issues you'll catch this way: wrong database credentials in wp-config.php, missing .htaccess rules, PHP version mismatches that break plugins, file permission problems that prevent uploads.
2. Forgetting to lower your DNS TTL ahead of time
You update the A record and expect the change to propagate in minutes. Two hours later half your traffic is still hitting the old server. The other half sees the new one, and now you have split traffic—some users creating content on the old host, some on the new.
DNS records have a TTL (time to live) value that tells resolvers how long to cache them. If your A record has a TTL of 86400 seconds (24 hours), recursive resolvers around the world will keep using the old IP for up to a day after you change it.
Lower the TTL to 300 or 600 seconds at least 24-48 hours before the migration. That lets the old, long TTL expire. When you make the actual DNS change, the new record propagates in 5-10 minutes instead of hours.
After the migration settles, raise the TTL back to 3600 or higher to reduce DNS query load.
3. Migrating while the old site is still live and accepting changes
You copy the database at 10 AM, upload files, test, and finally switch DNS at 2 PM. A customer places an order at noon. That order exists in the old database but not the new one. When DNS switches, the order vanishes.
Any change made on the old site after you export the database will be lost unless you re-export. For a busy site that's a real problem.
Put the old site into maintenance mode before you start the migration. Use a plugin or drop a .maintenance file in the WordPress root:
<?php $upgrading = time(); ?>
Visitors see a "briefly unavailable for maintenance" message. You export the database, copy files, set up the new host, test, and switch DNS—all while the old site is frozen. Once DNS propagates and you confirm the new site is serving traffic, you can retire the old host.
If you absolutely can't take the site offline, you need a different strategy: sync files and database to the new host, switch DNS, then immediately re-sync any changes that happened during propagation. That's more complex and still risks a few seconds of split-brain writes.
4. Not updating hardcoded URLs in the database
WordPress stores the site URL in dozens of places: wp_options, post content, serialized metadata, widget settings. If you migrate from old-host.com to example.com without updating these, you'll see broken images, redirects to the old domain, and missing CSS.
You can't just run UPDATE wp_posts SET post_content = REPLACE(post_content, 'old-host.com', 'example.com') because WordPress serializes arrays and objects in many fields. A naive find-and-replace breaks serialization by changing string lengths.
Use WP-CLI or a tool like Better Search Replace (the plugin) or Search-Replace-DB (the script). WP-CLI is the cleanest:
wp search-replace 'https://old-host.com' 'https://example.com' --all-tables
Run this on the new server after importing the database but before you go live. Check serialized fields like wp_options and wp_postmeta to confirm nothing broke.
If the new host has a different directory path (e.g., /home/olduser/public_html vs /home/newuser/public_html), you may also need to replace filesystem paths in the database, especially if you use certain backup or caching plugins.
5. Ignoring file permissions and ownership
You upload files via FTP as user ftpuser, but PHP runs as nobody or www-data. WordPress can't write to wp-content/uploads because the owner is wrong. Users can't upload images. Auto-updates fail.
File permissions are one of the most common support tickets I see after migrations.
Set directories to 755 and files to 644 as a baseline:
find /home/username/public_html -type d -exec chmod 755 {} \;
find /home/username/public_html -type f -exec chmod 644 {} \;
Then make sure ownership matches the user that PHP runs as. On cPanel this is usually your cPanel username:
chown -R username:username /home/username/public_html
On some VPS setups PHP-FPM runs as www-data or a pool-specific user—check your PHP-FPM pool config to be sure.
6. Skipping the PHP version check
The old host runs PHP 7.4. The new host defaults to PHP 8.1. You switch DNS and the site throws fatal errors because a plugin you forgot about uses deprecated functions.
PHP version mismatches are sneaky. The migration steps all work—files copy, database imports—but the site breaks at runtime.
Before you migrate, check the PHP version on the old host. In cPanel it's under MultiPHP Manager or you can create a phpinfo.php file:
<?php phpinfo(); ?>
Set the new host to the same major version before you test. Once the site is stable you can plan an upgrade, but doing it during the migration adds unnecessary risk.
Also check PHP extensions. Some hosts enable imagick by default, others don't. If a plugin depends on an extension that's missing on the new host, install it or switch to a different plugin before DNS cutover.
7. Forgetting to migrate email accounts and forwarders
You move the website but leave the MX records pointing to the old host because "email still works." A week later the old host suspends the account for non-payment. Email stops.
Or you update MX records along with the A record, but you forgot to recreate email accounts on the new host. Mail starts bouncing.
Decide where email will be hosted before you migrate. If the new host will handle email, export all accounts, forwarders, and filters from the old cPanel (or manually document them) and recreate them on the new host before you touch DNS.
If you use a third-party mail provider like Google Workspace or Outlook, MX records already point there and you don't need to do anything—just make sure you're not hosting email on the old server.
If you want to keep email on the old host temporarily, don't change the MX records. Only change the A and CNAME records for the website. Be aware that some hosts tie email and website together and may not let you keep email after you cancel the hosting plan.
8. Not keeping a backup of the old site until you're certain
You finish the migration, DNS propagates, everything looks good. You cancel the old hosting account to stop paying for it. Two days later you discover a plugin feature that's broken and you need to check the old config—but the old host already wiped the files.
Keep the old hosting account active for at least a week after the migration. Take a full backup (files and database) and store it locally before you cancel.
If something breaks on the new host and you can't fix it quickly, you can revert DNS to the old IP and buy yourself time to troubleshoot. Without that safety net, you're forced to fix issues under pressure while the site is down.
9. Not verifying SSL/TLS certificates on the new host
You switch DNS and visitors get a browser warning: "Your connection is not private." Turns out the new host's auto-SSL hadn't issued a certificate yet, or it issued one for the wrong domain variant, or it's using a self-signed cert.
Before you update DNS, check the SSL certificate on the new host. If the host uses AutoSSL or Let's Encrypt, you may need to manually trigger certificate issuance, and you can't do that until DNS points to the new server—which creates a chicken-and-egg problem.
Solution: issue the certificate using DNS validation instead of HTTP validation. Let's Encrypt supports the dns-01 challenge, which works even when DNS still points elsewhere. You add a TXT record, request the cert, then switch the A record afterward.
Or temporarily add the domain to your hosts file (like in mistake #1), issue the cert using HTTP validation while testing, and it'll already be in place when you go live.
If the new host doesn't support Let's Encrypt or you need an EV certificate, upload it manually through cPanel or WHM before the DNS cutover.
So how do you actually do a zero-downtime migration?
Put it all together and the sequence looks like this:
- Lower DNS TTL to 300 seconds, wait 24 hours.
- Check PHP version and extensions on the old host.
- Take a full backup of files and database on the old site.
- Put the old site into maintenance mode.
- Set up the new hosting account with matching PHP version.
- Upload files to the new host (rsync, FTP, or cPanel file manager).
- Import the database on the new host.
- Update
wp-config.phpwith new database credentials. - Run search-replace to update URLs if the domain is changing.
- Fix file permissions and ownership.
- Issue SSL certificate on the new host (DNS or HTTP validation).
- Add new server IP to your local hosts file.
- Test the site thoroughly: front-end, admin, forms, checkout.
- Recreate email accounts on the new host if needed.
- Update A and CNAME records to point to the new IP.
- Monitor traffic and error logs for the first hour.
- Take the old site out of maintenance mode only after confirming the new site is serving traffic.
- Keep the old hosting account active for at least a week.
- Raise DNS TTL back to 3600 after everything stabilizes.
This checklist eliminates most of the common mistakes and gives you a rollback path at every step.
Do I need to take the site offline during migration?
Not always. If it's a low-traffic site or a site that doesn't accept user-generated content, you can migrate while live and accept a few seconds of split traffic during DNS propagation. For a store or a membership site, maintenance mode is safer.
How long does DNS propagation actually take?
If you lowered the TTL in advance, most resolvers pick up the change in 5-10 minutes. Some ISPs and mobile networks cache more aggressively and can take an hour. Globally, you're usually safe after 2-3 hours. You can check progress with a tool like DNS Checker.
Can I migrate just the website and leave email on the old host?
Yes, as long as the old host allows it. Keep MX records pointing to the old IP and only change the A and CNAME records. Some shared hosting providers tie email to the website and may not let you keep email after you cancel. Check with support before you commit.
What if I find a problem after I've already switched DNS?
If you kept the old site intact, revert the DNS A record back to the old IP. If you lowered TTL properly, most visitors will start seeing the old site again within 10 minutes. Fix the issue on the new host, test again with the hosts file method, then switch DNS a second time.
Should I use a migration plugin instead of doing it manually?
Plugins like Duplicator, All-in-One WP Migration, or Migrate Guru can simplify the process, especially if you're not comfortable with command-line tools or database exports. They handle serialized data and can automate search-replace. The tradeoff is less control and sometimes size limits on free tiers. For large or complex sites, manual migration with WP-CLI gives you more visibility into what's happening.
What to check first
The majority of migration disasters happen because someone skipped testing or rushed the DNS change. You can't undo DNS propagation quickly, so that last step is the most critical.
Test the new host with the hosts file trick. Verify that everything works before you make the cutover public. Keep the old host online as a fallback for at least a few days. Lower your TTL so you can revert fast if you need to.
Follow that pattern and the migration is boring—which is exactly what you want.