How to Migrate a WordPress Site to a New Host: Step-by-Step Guide

Moving WordPress to a new host comes down to three jobs: copy the files and the database, make the new server serve the site correctly, then point the domain at it. Most migrations that go wrong skip the quiet part in the middle: testing the copy on the new server before visitors are sent there.

This guide covers every common method, the exact order of steps, how to test before you change DNS, and how to fix the errors people hit most often. If your domain is also changing, read how to move WordPress to a new domain as well, because that adds URL rewriting and redirects.

What is the safest way to move WordPress to a new host?

Copy the site to the new host while the old one stays live, test the copy on the new server, and only then switch DNS. Keep the old hosting account running for at least a week after the switch so you can fall back if something was missed. The method you use to copy the site matters less than following that order.

Google’s own guidance for changing hosts follows the same pattern: upload a copy to the new host, check that Googlebot can reach it, lower your DNS TTL in advance, then update DNS and monitor. When the domain and URLs stay the same, Google treats it as a hosting change rather than a site move with URL changes, so there are no redirects to plan.

Which migration method should you use?

There are five realistic ways to move a WordPress site. Each one is a valid choice in the right situation.

If your site is over a few gigabytes, or a previous archive-based attempt failed, read how to migrate a large WordPress site without upload limits first.

Before you start: prepare both servers

1. Take a full backup and store it off the server. Files and database, saved somewhere that is not the old host. This is your safety net if anything goes wrong on either side.
2. Write down versions. Note the PHP, MySQL or MariaDB and WordPress versions on the old host. Set the new host to the same PHP version or newer, never older, because plugins and themes may depend on it.
3. Lower the DNS TTL a day ahead. Set the TTL on your domain’s A or AAAA record to something short, such as 300 seconds. When you switch later, visitors and crawlers pick up the new server faster.
4. List what lives outside WordPress. Email accounts on the old host, cron jobs, custom server rules, subdomains and the SSL certificate do not travel with a WordPress migration. Recreate them on the new host.
5. Install a fresh WordPress on the new host. Most methods, including server-to-server plugins, need a working WordPress install on the destination to receive the site.

The full list, in order, is in our WordPress migration checklist.

Step by step: migrate server to server with SwiftMigrate

This is the method that avoids downloading anything to your computer. It works on shared hosting without SSH, because the two WordPress sites talk to each other directly through the WordPress REST API.

1. Install SwiftMigrate on both sites. In each WordPress admin go to Plugins → Add New Plugin, search for “SwiftMigrate”, install and activate it. The new site can be a blank WordPress install on a temporary address.
2. Generate a key on the new host. Open SwiftMigrate → Receive a site → Generate migration key and copy it. The key contains the new site’s address and a one-off secret, and expires after 24 hours by default.
3. Connect from the old host. Open SwiftMigrate → Send this site, paste the key and click Connect. A pre-flight check compares PHP versions, transport security, free disk space and the request size both servers accept.
4. Choose what to move and start. Database, media, themes, plugins, WordPress core and other root files are all selected by default. Files and database travel in parallel, checksummed chunks. You can close the tab and resume later.
5. Restore when every chunk is verified. The new host confirms every chunk on arrival and asks for anything missing or damaged again. Only then does the Restore button appear.
6. Log in with the old site’s details. The new host now holds the old site’s database, so the usernames and passwords are the ones from the old site.
7. Keep or roll back. After testing, delete the rollback copy to free disk space, or roll back if something is wrong.

SwiftMigrate never copies wp-config.php, .htaccess, .user.ini, php.ini or web.config, so the new host keeps its own database login and server rules. It does not support multisite networks. Details are on the SwiftMigrate page.

The manual method, if you prefer full control

The WordPress Advanced Administration Handbook describes the manual route. When the domain stays the same, it is mostly copying:

1. Copy all files from the old host to the new one over SFTP, including wp-content.
2. Export the database on the old host (phpMyAdmin or wp db export) and import it on the new one.
3. Edit wp-config.php on the new host with the new database name, user, password and host.
4. Save permalinks once in Settings → Permalinks so the rewrite rules are regenerated.

If the URL changes at any point, even temporarily for testing, do not run a plain find-and-replace on a database dump. Some themes and plugins store values with their length recorded, and a plain replace breaks them. Use a serialization-safe tool instead, such as WP-CLI:

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

Remove --dry-run once the preview looks right. The handbook is explicit that the guid column must never be changed.

Test on the new host before you switch DNS

This is the step that separates calm migrations from stressful ones. Your domain still points at the old host, so you need a way to see the new copy:

• Edit your computer’s hosts file to point your domain at the new server’s IP address. Only your computer sees the new host, so you test the real domain, SSL and all.
• Use a temporary URL if your host provides one. Keep in mind that a different address means WordPress URLs need rewriting for the test.

Then click through the site as a visitor and as an admin. Check the homepage, a few posts and pages, images, menus, contact forms, search, the checkout if you run a store, and the admin dashboard. Look at the PHP error log on the new host. Google also recommends confirming that Googlebot can reach the new infrastructure and checking that firewall or DoS protection on the new host is not blocking it.

Switch DNS and monitor the move

When the copy works, update the A or AAAA record (or the nameservers) to the new host. Because you lowered the TTL earlier, most visitors arrive at the new server within minutes to a few hours. During propagation some people still reach the old host, so avoid publishing or taking orders on the old site in that window.

After the switch:

• Check that the SSL certificate is valid on the new host for both the bare domain and www.
• Watch the new host’s error log and Search Console’s crawl stats. Google notes that a temporary dip in crawl rate after a hosting change is normal and usually recovers within days.
• Do not use Search Console’s Change of Address tool for a host move. It is only for moving to a different domain.
• Keep the old hosting account for at least a week, then cancel it once traffic has fully moved.

Common problems after moving hosts, and fixes

“Error establishing a database connection”

The database details in wp-config.php on the new host are wrong, or the database was not imported. Check the database name, user, password and host value your new provider gave you.

White screen or critical error

Usually a PHP version or extension mismatch. Compare versions with the old host, enable WP_DEBUG_LOG temporarily and read wp-content/debug.log.

Transfer blocked with HTTP 401, 403 or 406

A security plugin or the host’s firewall is blocking the REST API or binary uploads. In SwiftMigrate, turn on Firewall-friendly mode on the sending site, or allow requests to /wp-json/swiftmigrate/v1/transfer on the new site for the duration of the move.

Broken images or mixed content warnings

Some URLs still point at http:// or an old address. Run a serialization-safe search and replace, and check hard-coded URLs in theme files and page builder settings.

Emails stop arriving

Mail usually lived on the old host. Recreate mailboxes or point MX records to your email provider, and set up SMTP for WordPress’s own messages.

If you would rather have the migration planned and checked by people who do this regularly, our website management team can run it, and our technical SEO team can monitor indexing afterwards. For every method and tool in one place, start at our WordPress migration guide.