Why migrations usually cause downtime — and how to avoid it

The naive approach to migrating WordPress is: copy the files and database to the new host, change DNS to point at the new server, and hope everything works. The problem is that DNS changes don't happen instantly for every visitor — different ISPs and DNS resolvers cache records for different lengths of time, so for a window ranging from minutes to (in the worst case) a couple of days, some visitors will hit the old server and some will hit the new one.

If the new server isn't fully working when that window opens, a meaningful slice of your visitors see a broken or incomplete site. The fix is straightforward: build and fully test the site on the new host before DNS ever changes, using a method that lets you view the new server as if you were a normal visitor, without affecting anyone else.

The core idea: get the new server completely ready and verified first. Only change DNS once you've confirmed, with your own eyes, that the new host is serving a fully working copy of the site. DNS becomes the very last step, not an early one.

Before you start

1 Lower your DNS TTL in advance

If you have access to your current DNS records, lower the TTL (time to live) on your domain's A record to 300 seconds (5 minutes) at least 24 hours before migrating. This tells DNS resolvers around the world to stop caching the record for as long, which means once you do make the actual change, most visitors will see the new server within minutes rather than hours.

2 Take a full backup of the current site

Before touching anything, take a complete backup — files and database both — of the site on its current host. Most cPanel hosting includes a backup tool under Files → Backup. If you're not sure your current host has one, a plugin like UpdraftPlus or All-in-One WP Migration can produce a portable backup you can download.

3 Note your current PHP version and active plugins

Write down the PHP version your site currently runs on and the full list of active plugins and their versions. This becomes your checklist for confirming the new environment matches closely enough that nothing breaks on the move.

Moving the site to the new host

Files

Copy the entire WordPress installation — typically the public_html directory or your site's specific subdirectory — to the new host. This can be done via SFTP, or if both hosts support it, directly server-to-server which is usually faster:

# From the old server, copy the WordPress directory directly to the new host
rsync -avz --progress /home/oldsite/public_html/ \
  user@newhost.example.com:/home/newsite/public_html/

If you don't have shell access on either host, downloading a zip via cPanel's File Manager and uploading it to the new host works just as well — it's just slower for larger sites.

Database

Export the WordPress database from the old host using phpMyAdmin or the command line:

# Export the database to a .sql file
mysqldump -u dbuser -p old_database_name > site_backup.sql

# On the new host, create a fresh database, then import
mysql -u newdbuser -p new_database_name < site_backup.sql

Update wp-config.php on the new host with the new database name, username, password, and host (usually localhost, but check with your new provider — some require a specific database host address).

Common mistake: forgetting to update wp-config.php database credentials after copying files across. The site will show a "Error establishing a database connection" message until this is corrected — this is expected at this stage and not a sign anything else is wrong.

Testing the new site before DNS changes

This is the step that actually prevents downtime, and it's the one most guides skip over. You need to view the site running on the new server, using your actual domain name, before any public DNS change happens.

Editing your hosts file

Every operating system has a hosts file that lets you manually map a domain name to an IP address on your own machine, overriding public DNS just for you. Find your new host's server IP address, then add an entry:

# macOS / Linux — edit /etc/hosts (requires sudo)
# Windows — edit C:\Windows\System32\drivers\etc\hosts (run as Administrator)

123.45.67.89    yourdomain.com.au
123.45.67.89    www.yourdomain.com.au

Save the file, flush your local DNS cache, and visit your site in a browser. You should now see the new server's version of the site, addressed by your actual domain name — exactly as a real visitor would see it once DNS changes, except only you can see it this way.

What to check while testing

Take your time here. This is the entire point of the no-downtime approach — issues found now cost you nothing, because no visitors are affected yet. Issues found after DNS has switched are a much bigger problem to untangle.

Cutting over — the DNS change itself

Once you're satisfied everything works correctly on the new host, remove the hosts file entry you added earlier (so you'll see the live, real-world result once DNS changes) and update your domain's DNS records to point at the new server's IP address.

If you lowered the TTL in advance as suggested earlier, most visitors will be redirected to the new server within 5-15 minutes. Without a lowered TTL, expect this to take anywhere from a few hours up to 24-48 hours for some visitors, depending on their ISP's DNS caching behaviour.

During this transition window, both servers should ideally remain active and serving identical content — this is exactly why you took that backup and tested thoroughly beforehand. Some visitors will briefly hit the old server, some the new one, but since both are serving working copies, nobody sees a broken site either way.

After the migration

Post-migration checklist

  • Confirm SSL certificate is valid and HTTPS redirects work correctly on the new server
  • Check Google Search Console for any new crawl errors over the following week
  • Verify scheduled tasks (WP-Cron, any custom cron jobs) are running on the new host
  • Test email deliverability — sending and receiving — if email is hosted alongside the website
  • Update any hardcoded IP addresses or server-specific configuration in plugins
  • Once confident everything is stable (give it at least a week), decommission the old hosting account

A few specific questions worth addressing

Do I need to change the WordPress site URL?

If you're keeping the same domain name and only the hosting server is changing, no — the siteurl and home values in the WordPress database don't need updating. These only need changing if you're also switching domain names, or moving from a staging URL to the production domain.

What if my current host doesn't give me shell access?

Most cPanel-based hosts provide a "Backup Wizard" or similar tool that bundles your files and database into downloadable archives — no shell access required. The process is slower than direct server-to-server transfer, but works just as reliably for sites that aren't enormous.

Migrating a site and want it handled properly?

If you'd rather not be the one testing hosts file entries at 11pm, get in touch. WordPress migrations are routine work when done in the right order.

Send an enquiry
← All resources Also read: cPanel vs VPS hosting →