How to move a WordPress site to a new host without downtime

Moving a WordPress site to a new host without downtime is possible, because the old and the new host can run at the same time. While you copy the site, visitors see the old one. They reach the new one only when you change the DNS records, and by then you have looked at it and checked it.

The order matters. First you lower the TTL of the DNS records, then you copy the files and the database and upload them to the new host. Before you change DNS, you test the site through the hosts file on your computer and sort out the mail. Last, you change DNS, issue the SSL certificate and check with dig.

Get ready before you copy anything

Domain registration and the domain's DNS records are two separate things. The records may be at the registrar, in Cloudflare or at the old host. If they are at the old host, move them before you cancel it, and if the registration is there too, see domain transfer. The commands show where the domain points.

# From your computer. Name servers, mail and the site's record.
dig +short primer.bg NS
dig +short primer.bg MX
dig +noall +answer primer.bg A
# The same, but you ask one of the name servers from the first line.
dig @NAME_OF_NS_SERVER +noall +answer primer.bg A

The second column of the answer is the TTL in seconds. It is the time other servers remember the answer for. An ordinary DNS server shows how much of it is left, and the real value comes from the domain's own name server. Write down the TTL and all the records of the DNS zone.

According to Cloudflare's documentation, a longer TTL speeds up lookups but slows down changes taking effect. So at least a day before the move, lower the TTL of the A records of the domain and of www to 300 seconds, that is, 5 minutes. If the old TTL is longer than a day, start that much earlier, because the new value applies only when the cache holding the old one expires.

Make a full copy of the files and the database

A site has two parts, and you need both. The files are the whole folder of the site, with wp-content (themes, plugins, images), wp-config.php and the hidden .htaccess. The database holds the pages, posts, comments and settings.

If the old host has Terminal in cPanel and WP-CLI, a few lines do it. The first command writes the database to an SQL file, and the second makes an archive of the site's folder. Both files go to the home folder, not to public_html, so that nobody can download them from a browser.

# cPanel > Terminal on the old host
cd ~/public_html
wp db export ~/primer-bg.sql
zip -r ~/primer-bg-files.zip .

The dot at the end of zip includes hidden files such as .htaccess. Without Terminal, use the interface. In File Manager turn on Show Hidden Files in Settings, select everything in the site's folder, choose Compress and download the archive. Export the database from phpMyAdmin with Export, the Quick method and the SQL format.

If the site is being written to, for example with orders, comments or forms, make the copy in the quietest hour.

Upload the site to the new host

On the new host the work comes in five steps.

1. Make sure the domain is added to the account in cPanel, as the main or an addon domain, so that the new server has a site for it.
2. Create a database and a user in MySQL Database Wizard or in Manage My Databases, not in phpMyAdmin, because cPanel does not keep track of databases created that way and their backups do not work. Give the user privileges on the database. The host may add a prefix with the account name to the names, so write down the exact names.
3. Upload the archive to the site's folder and extract it with Extract in File Manager.
4. Put the new database details in wp-config.php.
5. Import the SQL file.

// wp-config.php on the new host
define( 'DB_NAME', 'YOUR_USERNAME_primer' );
define( 'DB_USER', 'YOUR_USERNAME_primer' );
define( 'DB_PASSWORD', 'YOUR_PASSWORD' );
define( 'DB_HOST', 'localhost' );

DB_HOST is localhost unless the new host gives you another address. The rest of the file stays as it is, because it comes from the old site. The import can be done in phpMyAdmin with Import or in Terminal. The command reads the access details from wp-config.php, so run it in the site's folder.

# cPanel > Terminal on the new host, in the site's folder
wp db import ~/primer-bg.sql

If the SQL file is too big for phpMyAdmin, use Terminal, because PHP's limits on size, memory and time restrict uploads through the browser. The site's address stays the same, so do not touch siteurl and home. Search and replace in the database is needed only when the domain changes. If you see "Error establishing a database connection", first check the name, user, password and host in wp-config.php.

Test the new site through the hosts file

While DNS still points to the old host, you can make only your own computer open the domain from the new server. This is done with the hosts file, where you write the new server's IP address for the domain. The computer checks this file before it asks DNS, and everyone else keeps seeing the old site. Get the IP address from the new host's email or from its support.

On Windows, open Notepad with Run as administrator, then File, Open and the path from the first line of the block (change the file type to All files if you cannot see the file). On macOS, use the command below. The line is the same for both systems.

# Windows: C:\Windows\System32\drivers\etc\hosts
# macOS: /etc/hosts
203.0.113.10  primer.bg www.primer.bg

# Terminal on macOS
sudo nano /etc/hosts

Save the file. On macOS you save with Ctrl+O and Enter and exit with Ctrl+X. On Windows, flush the DNS cache, and if the browser still shows the old site, close it completely and open it again.

# Windows, Command Prompt
ipconfig /flushdns

Open https://primer.bg in a new window. The browser may warn about the certificate, because the new server does not have one for your domain yet. Continue only if you are sure the hosts file points to your new server. To make sure you are on it, upload a file test.txt to the site's folder (delete it after the test) and open it at /test.txt. If the browser does not let you continue, use curl.

# From your computer. A request to the new server, no hosts file.
# The -k option skips the certificate check, for this test only.
curl -skI --resolve primer.bg:443:203.0.113.10 https://primer.bg/

Go through the home page, the inner pages, the images, the admin login and the forms. On a 500 error, rename .htaccess to .htaccess_old, because according to WordPress the most common cause is a corrupted .htaccess, and then save Settings > Permalinks so that a new one is made. Also check the PHP version in Tools > Site Health > Info > Server. If it is newer than the old one, some plugin may not be ready for it.

Do not lose the mail during the switch

Mail follows the MX records. An MX record points to a name, and that name has its own A record. If MX points to the domain itself or to mail.primer.bg and you change the A record of that name, the mail also starts going to the new server, where your mailboxes do not exist yet. Check where MX points and what A record the name in the answer has.

If the mail is with another provider, for example Google Workspace or Microsoft 365, the MX records are not touched. In the new cPanel, open Email Routing and choose Remote Mail Exchanger. Automatic detection looks only at the server's own zone, does not do a real DNS lookup and may decide that the mail is local. Then mail from the site to addresses on your domain, for example from the contact form, can stay on the server. A wrong setting here can stop mail from arriving, so if in doubt ask your host.

If the mail is on the old host, move it separately and later than the site. Create the same mailboxes on the new host, add the old and the new mailbox to a mail client over IMAP and move the folders from the old one to the new one. Change the MX records only when the new mailboxes are ready, and give them a low TTL.

When the DNS zone moves together with the site, copy the TXT records too. They hold SPF, DKIM and DMARC, which other servers use to check that the mail from your domain is genuine. How to check them is described in the guide to SPF, DKIM and DMARC.

Change the DNS records without downtime

When the new site is checked and the mail is sorted out, it is the turn of DNS. What exactly you change depends on where the zone is.

• The zone stays where it is, at the registrar, in Cloudflare or at the old host if you keep it for DNS. You change only the A records of the domain and of www to the new server's IP address. This is the fastest way, because the TTL you lowered applies.
• The zone moves to the new host. First recreate all the records there, compare them with dig against the new name servers and only then change the name servers at the registrar. This change goes through the registrar and may show up later than a single record with a low TTL. If the domain has DNSSEC, turn it off at the registrar first, because according to Cloudflare, changing name servers while DNSSEC is active can make the domain unreachable.

; Zone Editor in cPanel, the registrar's panel or Cloudflare
primer.bg.      300  IN  A  203.0.113.10
www.primer.bg.  300  IN  A  203.0.113.10

Until the caches update, some visitors are on the old server and some on the new one. For a blog this does not matter. On a shop or a site with forms, an order, comment or enquiry may land on the old server after your copy and be missing on the new one. So shortly before the switch, make a new copy of the database from the old site and import it into the new one with the same commands, at an hour with few orders. After the switch, keep looking at the old site too and move by hand whatever arrived there.

Issue the SSL certificate after the DNS switch

While the domain points to the old server, a certificate cannot be issued on the new one. Before it issues a certificate, AutoSSL checks that the domain is yours, and most often this is done with a verification file that is opened at the domain's address. So the check passes only after the DNS switch.

Open SSL/TLS Status in cPanel and choose Run AutoSSL. When the certificate is issued, open https://primer.bg and https://www.primer.bg and check the padlock. In Tools > Site Health > Info > WordPress the row "Is this site using HTTPS?" should also confirm that the site uses HTTPS.

Check with dig and keep the old host for about another week

The commands below ask different servers, so you can see whether all of them already know the new address.

# From your computer. Expect the new server's address, 203.0.113.10.
dig +short primer.bg A
dig @1.1.1.1 +short primer.bg A
dig @8.8.8.8 +short primer.bg A

On Windows without dig, use nslookup primer.bg 1.1.1.1. When all of them answer with the new address, remove the line from the hosts file, put the TTL back to a higher value and delete the SQL file and the archive from both hosts.

Keep the old host for about another week. That way you have a way back, and the mail and the visitors who are still on the old server are not lost. During this time, look at both places for new mail and orders. When everything is in its new place, cancel the old host, but first make sure it does not hold your domain and its DNS zone.

Checklist

• The old host stays active to the end.
• You know where the domain registration and the DNS zone are, and the records are saved.
• The TTL of the site's records has been 300 seconds for at least a day.
• There is a copy of the files and the database, and the SQL file and the archive are not in the site's folder.
• The domain is added on the new host, the database is imported, and wp-config.php has the new details.
• The site has been checked through the hosts file or with curl.
• The MX records were touched only when the new mailboxes were ready.
• A new copy of the database was made shortly before the switch.
• The A records point to the new server, dig confirms it, and SSL works without a warning.
• The line is removed from the hosts file, and the TTL is back to a higher value.
• The old host is kept for about another week.

If you would rather not move it yourself

A small site without mail on the same server is fairly easy to move. Shops and sites with mailboxes on the server need more care, and a mistake in DNS or in the mail shows up at once.

If you are moving the site because it has outgrown shared hosting, with moving to your own server we move it without downtime to Hetzner or AWS, onto a server that is yours. Tell us about the site and its mail in the inquiry form.

Sources

• WordPress, Migrating WordPress
• WordPress, Backing Up Your Database
• WordPress, Backing Up Your WordPress Files
• WordPress, Common WordPress Errors
• WordPress, Site Health screen
• WP-CLI, wp db export
• WP-CLI, wp db import
• phpMyAdmin, FAQ
• cPanel, Zone Editor
• cPanel, Email Routing
• cPanel, MySQL Databases
• cPanel, File Manager
• cPanel, SSL/TLS Status
• cPanel, Guide to SSL
• Cloudflare, Time to Live (TTL)
• Cloudflare, Full setup
• Let's Encrypt, Challenge Types
• BIND 9, dig
• curl, manual page
• Linux man-pages, hosts(5)
• Microsoft, PowerToys Hosts File Editor
• Microsoft, ipconfig