How to Transfer a WordPress Site to a New Host (No Downtime)

When you transfer WordPress to a new host, the files are the easy part. What breaks sites is the database: a URL stored in the wrong format, a wp-config.php still pointing at the old server, or a DNS switch made before anyone looked at the copy. This guide is the WordPress-specific version of our general zero-downtime migration sequence. It covers the backup, the plugin and manual routes, the DNS and testing tricks, SSL, email, and a checklist for the final switch.

Step 0: take a full backup first

Before you copy anything, make a backup you could restore from if both hosts disappeared tomorrow. A WordPress site is two things: the files (core, themes, plugins and, above all, wp-content/uploads) and one MySQL or MariaDB database. You need both, taken at roughly the same moment.

If the old host gives you SSH and WP-CLI, export the database from the site's root:

cd ~/public_html
wp db export ~/backup/site-$(date +%F).sql

wp db export reads the credentials from wp-config.php and runs mysqldump for you (WP-CLI documentation). Without WP-CLI, call mysqldump directly. --single-transaction gives a consistent copy without locking the live site:

mysqldump --single-transaction --quick \
  -u dbuser -p dbname | gzip > ~/backup/site-$(date +%F).sql.gz

Then pack the files:

tar -czf ~/backup/files-$(date +%F).tar.gz -C ~/public_html .

Download both archives to your own computer. A backup that only exists on the server you are leaving is not a backup.

No SSH at all? Most control panels have a full-account backup button, and phpMyAdmin can export the database as a .sql file. Slower, same result.

Plugin migration or manual migration?

There are two ways to do the copy, and both are reasonable.

The plugin route. A migration plugin installed on the old site packs files and database into one archive, and the same plugin on a fresh WordPress install at the new host unpacks it, rewriting URLs on the way. It needs no command line and suits a small site on a host without SSH. The catches: large sites can hit upload or execution time limits, some plugins put size caps or features behind a paid version, and when an import fails halfway the error messages are rarely helpful.

The manual route. You copy the files with rsync, import the database yourself and edit one config file. It takes a little more typing, but nothing is hidden, you can re-run any step, and it handles a 20 GB uploads folder as easily as a 200 MB one.

The rest of this guide follows the manual route, because it is the one where you need to know the steps.

How to transfer WordPress to a new host manually

1. Create the site and database on the new host

On our WordPress hosting and web hosting plans the panel is DirectAdmin. Add the domain to the account, then create an empty database and user under Account Manager → MySQL Management. Write down the database name, user and password; DirectAdmin prefixes both with your account name, so they look like myuser_wp.

Do not run the WordPress installer on the new domain. You are bringing your own WordPress.

2. Copy the files with rsync

If the new host gives you SSH, pull the files from the old server with rsync:

rsync -avz --progress \
  --exclude='wp-content/cache/' \
  --exclude='wp-content/upgrade/' \
  olduser@old-host.example:public_html/ \
  ~/domains/example.com/public_html/

On DirectAdmin each domain has its own document root at ~/domains/<domain>/public_html. Excluding the cache directory avoids copying gigabytes of files that will be rebuilt anyway. Because rsync only transfers what changed, you will run the same command again right before the switch.

Our web hosting and WordPress hosting plans do not include SSH. On those, and on any host without it, upload the files-*.tar.gz archive with the DirectAdmin File Manager or FTP and extract it in public_html from the File Manager. Or skip the work: our free migration does this part for you.

3. Import the database

gunzip < site-2026-10-16.sql.gz | mysql -u myuser_wp -p myuser_wp

That command needs SSH on the new host. If WP-CLI is available there, wp db import site.sql does the same thing once wp-config.php is updated. Without SSH, as on our web hosting, use phpMyAdmin's Import tab in DirectAdmin, which handles dumps of a few hundred megabytes.

4. Update wp-config.php

Point WordPress at the new database:

define( 'DB_NAME', 'myuser_wp' );
define( 'DB_USER', 'myuser_wp' );
define( 'DB_PASSWORD', 'the-new-password' );
define( 'DB_HOST', 'localhost' );

Check the $table_prefix line as well. If the old site used wp7x_ instead of wp_, it must stay wp7x_, or WordPress will think it is a fresh install. While you have the file open, look for hard-coded paths such as WP_CONTENT_DIR or a caching plugin's WP_CACHE line that refers to the old server's directory layout.

5. Run search-replace if the URL changes

If the domain stays the same, skip this step. If it changes, from a staging address to the real domain or from http:// to https://, do not edit the database by hand. WordPress stores many settings as serialised PHP data, where a string's length is saved next to it; a plain find-and-replace in a SQL file breaks those values, and widgets and theme settings quietly disappear. WP-CLI's search-replace handles serialised data correctly:

wp search-replace 'http://old.example.com' 'https://example.com' \
  --skip-columns=guid --dry-run

--dry-run shows how many replacements would be made without changing anything. Remove it to apply. Skipping the guid column follows the WP-CLI documentation, since post GUIDs are identifiers and should not change.

WP-CLI runs over SSH. On a host without it, a search-and-replace plugin that understands serialised data does the same job from the WordPress dashboard; run it once on the new copy before the DNS switch.

Lower the DNS TTL 24 to 48 hours before

The TTL is how long resolvers around the world remember your current IP address. If it is set to a day, some visitors keep reaching the old host for a day after you switch. Check the current value:

dig example.com A +noall +answer
# example.com.  14400  IN  A  203.0.113.10

The second column is the TTL in seconds. At your DNS provider, lower it to 300 for the A record, the www record and the MX record, then wait at least as long as the old TTL before switching. Doing this 24 to 48 hours ahead is what turns the switch into a five-minute event instead of a day of split traffic.

Test the new host with the hosts file

Now check the copy without touching public DNS. Your hosts file overrides DNS for your own computer only, so you can open the real domain on the new server while every other visitor still sees the old one.

# macOS / Linux
sudo nano /etc/hosts

On Windows, open Notepad as Administrator and edit C:\Windows\System32\drivers\etc\hosts.

Add one line with the new server's IP:

198.51.100.25  example.com www.example.com

Open the site in a private browser window and work through it: the home page, a few posts, an image from an old month in the uploads folder, the contact form, and a login to /wp-admin. On a shop, place a test order. If pages work but links point to the old address, revisit the search-replace step. If you see "Error establishing a database connection", the credentials or the host in wp-config.php are wrong; check them against the database you created in step 1.

A certificate warning at this stage is expected. Remove the hosts line when you have finished.

SSL on the new host

Let's Encrypt validates over HTTP, so it can only issue a certificate once the domain points at the new server. In practice: switch DNS, wait for the record to change, then request the certificate under Account Manager → SSL Certificates and tick Force SSL with https redirect under Domain Setup. With the TTL at 300 seconds, the window without a valid certificate is a few minutes. The full walkthrough, including the mail. name and CAA records left by previous hosts, is in free Let's Encrypt SSL in DirectAdmin. Certificates renew automatically after that.

Email: the part people lose

If your mailboxes are at a separate provider, such as Google Workspace or Microsoft 365, leave the MX records exactly as they are and copy them across unchanged if you are also moving DNS. Nothing else to do.

If your mail lives on the old host, it has to move too:

1. Create the same mailboxes on the new host, with passwords you will hand to their users.
2. Copy the messages over IMAP with imapsync, which can be re-run to pick up new mail:

imapsync --host1 mail.old-host.example --user1 you@example.com --password1 'old-pass' \
         --host2 mail.example.com --user2 you@example.com --password2 'new-pass'

3. Change the MX record, and update the SPF record so it allows the new server to send for your domain.
4. Run imapsync once more a few hours later to catch anything that reached the old server during the switch.

The risk is the gap: for as long as some senders still see the old MX record, mail keeps landing on the old host. That is why the old account must stay active, with its mailboxes intact, for at least a week after the move.

The cut-over checklist

On the day, in this order:

• TTL lowered at least 24 hours ago, confirmed with dig
• Copy tested through the hosts file, hosts line removed
• Old site frozen: no new posts, comments closed or a maintenance notice for ten minutes
• Final rsync of the files and a fresh database dump imported
• A and www records changed to the new IP
• dig +short example.com A @1.1.1.1 returns the new IP
• Let's Encrypt certificate issued and HTTPS forced
• Permalinks re-saved under Settings → Permalinks to regenerate .htaccess
• Caching plugin cache cleared, and the old host's caching plugin settings checked against the new server
• MX and SPF updated if mail moved, last imapsync run
• Cron, contact forms and outgoing email tested from the new server
• Old hosting kept for a week, then cancelled

The general version of this sequence, for sites that are not WordPress, is in how to move a website to a new host without downtime.

Moving many sites at once

If you are an agency or a reseller moving a dozen client sites, the steps per site are the same, but the order and communication matter more: which clients have mail on the old host, who controls each domain's DNS, and when each switch happens. Our agency checklist for moving client sites covers that. If the plan is to host those clients under your own brand afterwards, reseller hosting explained shows how one panel is cut into separate client accounts.

Or let us do it

Every step above is what our team does when you ask for a free migration. We move the files, databases, email and SSL, and you run the site on our servers for a week before paying. The plans, with WordPress Manager for staging and cloning and AccelerateWP caching, are on the WordPress hosting page.

Frequently asked questions