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

Moving WordPress means copying two things, the files and the database, then pointing your domain at the new server without breaking links, SSL, search rankings or email. Pick the method that matches the size of the site and your comfort with technical tools.

The host matters more than the migration method. Match it to your traffic, budget and where your visitors are; for an Australian audience, a nearby data centre keeps pages fast.

Affiliate disclosure: we may earn a commission if you sign up through these links, at no extra cost to you. It never changes our recommendations.

Tools that make the move easier

Full comparison: WordPress hosting in Australia →

1. 1

   Record the current setup

   Where: Old site: WordPress admin > Tools > Site Health > Info tab, plus an SSH session in the WordPress folder (or the host's control panel)

   Note the PHP and MySQL/MariaDB versions, WordPress version, active theme and plugins, database size, cron jobs and any server rules in .htaccess or Nginx config. The Site Health Info tab lists most of these; WP-CLI gives the rest. If wp --info fails, install WP-CLI first.

   wp core version
   wp theme list --status=active
   wp plugin list --status=active
   wp db size --human-readable
   crontab -l

   You should see: A written record of versions, theme, plugins, database size and cron entries, saved with your project notes.
2. 2

   List every DNS record

   Where: The DNS settings at your current DNS provider (find it with dig NS), copied into the DNS cutover record sheet

   Export the full DNS zone: A, AAAA, CNAME, MX, TXT (SPF, DKIM, DMARC, verification records). You will need them if you change nameservers.

   dig +short NS contoso.com
   dig +short A contoso.com
   dig +short MX contoso.com
   dig +short TXT contoso.com

   You should see: Every record shown at the DNS provider is in the record sheet with its value and TTL.
3. 3

   Take a full backup you can restore

   Where: SSH session in the WordPress folder on the old host (or the host's file manager and phpMyAdmin), then your SFTP client to download

   Back up files and the database, download them, and keep a copy off the old host. The backup how-to covers the SFTP, WP-CLI, mysqldump and phpMyAdmin routes.

   wp db export backup-$(date +%F).sql
   tar -czf files-$(date +%F).tar.gz wp-content

   You should see: WP-CLI prints "Success: Exported to" the .sql file, the .tar.gz has a non-zero size, and both files are on your computer or cloud storage.
4. 4

   Lower the DNS TTL

   Where: The DNS settings at your current DNS provider

   At least 24 to 48 hours before the move, lower the TTL on the records you will change to 300 seconds so the switch propagates quickly. See lower DNS TTL before a migration.

   You should see: The records show a TTL of 300 at the DNS provider, and dig contoso.com shows it once the old TTL has passed.

1. 1

   Create the site and database

   Where: The new host's control panel: its add site or domain page, then its MySQL databases page

   Create an empty site, a new database and a database user with full rights to it. Match or exceed the old PHP version. Write down the database name, user, password and host for Step 3.

   You should see: The control panel lists the new site and the database, with the user assigned to the database.
2. 2

   Use a temporary or staging address

   Where: The new host's control panel (its temporary URL or staging feature), or your computer's hosts file

   Most managed hosts give a temporary URL or staging site so you can test before touching DNS. If yours does not, preview with the hosts file in Step 4.

   You should see: You have an address (temporary URL or hosts file entry) that reaches the new server.
3. 3

   Install SSL in advance where possible

   Where: The new host's control panel: its SSL or certificates section

   Some hosts can issue the certificate only after DNS points at them; plan to issue it straight after cutover.

   You should see: Either a certificate is shown as issued for the domain, or the runsheet has a cutover task to issue it.

1. 1

   Copy the files

   Where: SSH session on the new server (rsync pulls from the old host), or an SFTP client connected to both hosts

   Copy the whole WordPress folder, or at least wp-content, over SFTP or rsync. Change the user, host and paths to your own.

   rsync -avz --progress user@old-host:/var/www/html/ /var/www/html/

   You should see: rsync finishes with a summary line of bytes sent and received, and the new folder contains wp-content, wp-admin and wp-config.php.
2. 2

   Export and import the database

   Where: SSH on the old server (mysqldump), then SSH on the new server (mysql); or phpMyAdmin Export and Import tabs in each host's control panel

   Export from the old server, copy the .sql file across, and import into the new, empty database. The export and import how-to covers phpMyAdmin, large files and PowerShell quirks.

   mysqldump --single-transaction -u OLD_USER -p OLD_DB > site.sql
   mysql -u NEW_USER -p NEW_DB < site.sql

   You should see: Both commands return to the prompt with no ERROR lines, and the new database lists the same tables as the old one.
3. 3

   Update wp-config.php

   Where: The new server: wp-config.php in the WordPress folder (edit over SFTP, or with WP-CLI over SSH)

   Set the new DB_NAME, DB_USER, DB_PASSWORD and DB_HOST. Keep the same table prefix as the old site.

   wp config set DB_NAME NEW_DB
   wp config set DB_USER NEW_USER
   wp config set DB_PASSWORD 'NEW_PASSWORD'
   wp config set DB_HOST localhost
   wp db check

   You should see: wp db check ends with a Success line, and the site no longer shows "Error establishing a database connection".
4. 4

   Replace old URLs safely

   Where: SSH session on the new server, in the WordPress folder

   If the domain or protocol changes, run a serialisation-safe search and replace. Always dry-run first, and skip the guid column. See change WordPress URLs with wp search-replace for plugin tables and other forms of the address.

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

   You should see: The dry run shows replacement counts per table; the real run ends with a Success line, and wp option get home prints the new address.
5. 5

   Flush permalinks and caches

   Where: SSH session on the new server, in the WordPress folder (or WordPress admin > Settings > Permalinks > Save Changes)

   Regenerate rewrite rules and clear object and page caches. Clear any caching plugin's cache from its own settings page too.

   wp rewrite flush
   wp cache flush

   You should see: Both commands print a Success line, and inner pages load instead of returning 404.

1. 1

   Preview on the real domain

   Where: Your computer's hosts file (Notepad as administrator on Windows, Terminal on macOS)

   Point the domain at the new server's IP on your computer only, so you can browse the new copy before anyone else sees it. Follow test a site with the hosts file.

   203.0.113.10    contoso.com
   203.0.113.10    www.contoso.com

   You should see: ping contoso.com shows the new server's IP, and the browser loads the new copy.
2. 2

   Test what makes money

   Where: A private browser window on your computer, with the hosts file entries active

   Test contact forms, checkout and payments, logins, membership areas, search and any API integrations.

   You should see: Each form, payment and login works the same as on the old site, and test entries arrive where they should.
3. 3

   Look for broken assets

   Where: Browser developer tools (F12): Console and Network tabs

   Reload key pages and check images, fonts and scripts for 404s and mixed-content warnings in the console.

   You should see: No 404 responses in the Network tab and no mixed-content warnings in the Console.
4. 4

   Check scheduled tasks and email

   Where: SSH session on the new server (WP-CLI), then WordPress admin

   Confirm WP-Cron or the server cron runs, and that site emails (password resets, order emails) send through an SMTP service. Trigger a password reset to a test account.

   wp cron test
   wp cron event list

   You should see: wp cron test reports that WP-Cron spawning is working, and the password reset email arrives.

1. 1

   Freeze and do a final sync

   Where: WordPress admin on the old site (freeze), then SSH on both servers

   Stop content changes, then re-copy the database (and new uploads) if anything changed since your first copy. Re-run the URL replacement from Step 3 if the domain changes.

   mysqldump --single-transaction -u OLD_USER -p OLD_DB > final.sql
   mysql -u NEW_USER -p NEW_DB < final.sql
   rsync -avz user@old-host:/var/www/html/wp-content/uploads/ /var/www/html/wp-content/uploads/

   You should see: The newest post, order or form entry from the old site appears on the new site.
2. 2

   Update DNS records

   Where: The DNS settings at your DNS provider

   Point the A (and AAAA) record, or the CNAME, to the new host. If you change nameservers, recreate every record from your export first, especially MX and TXT (see change nameservers).

   dig +short A contoso.com
   dig +short MX contoso.com

   You should see: dig returns the new server's IP and the unchanged MX values. Check DNS propagation from other resolvers too.
3. 3

   Issue SSL and force HTTPS once

   Where: The new host's control panel: its SSL or certificates section

   Issue the certificate as soon as DNS resolves, then force HTTPS in one place only (host, plugin or server config) to avoid redirect loops.

   curl -I http://contoso.com/

   You should see: curl shows a single 301 to https://, and the browser shows a valid certificate with no warning.
4. 4

   Check the live site

   Where: A browser on your computer with the hosts file entries removed, and your email client

   Browse key pages, place a test order, submit a form and send a test email to and from the domain.

   You should see: Pages, orders and forms work on the live domain, and test emails arrive in both directions.

1. 1

   Search Console and sitemap

   Where: Google Search Console (search.google.com/search-console) > your property > Sitemaps report

   Verify the site in Google Search Console if it is not already, enter the sitemap address (WordPress core serves /wp-sitemap.xml unless an SEO plugin replaces it) in Add a new sitemap and select Submit. Watch the Pages report and 404s for two weeks.

   You should see: The sitemap shows status "Success", and the Pages report shows no new spike in "Not found (404)".
2. 2

   Redirect every changed URL

   Where: The .htaccess file or nginx server block on the new server, or WordPress admin > Tools > Redirection

   If URLs or the domain changed, add 301 redirects from every old URL to its new one (see set up 301 redirects). For a domain change, also use Search Console's Change of Address tool, as in the domain change guide.

   curl -I https://contoso.com/old-page/

   You should see: Each old URL returns 301 with a Location header pointing at the right new page.
3. 3

   Check speed and Core Web Vitals

   Where: PageSpeed Insights (pagespeed.web.dev) in your browser, and the new host's caching or CDN settings

   Compare page speed against the old host and enable caching and a CDN where available.

   You should see: Key pages score the same as or better than they did on the old host.
4. 4

   Keep the old host briefly

   Where: The old host's control panel and billing page

   Keep the old hosting for a week or two as a fallback, then download a final backup and cancel. Check email no longer depends on it before you cancel.

   You should see: A final backup is stored off both hosts, MX records do not point at the old host, and the old plan is cancelled.

1. 1

   Squarespace to WordPress

   Where: Squarespace: Import & export content panel > Export > WordPress; then WordPress admin > Tools > Import > WordPress

   Squarespace exports layout pages, gallery pages and one blog page in a WordPress-format .xml file. Import it in WordPress, then rebuild layouts, products and forms and map every old URL with 301 redirects. Full steps: Wix and Squarespace to WordPress.

   You should see: Posts and pages from the export appear in WordPress, and every page that did not export is on your rebuild list.
2. 2

   Wix to WordPress

   Where: Your Wix blog's RSS feed; then WordPress admin > Tools > Import > RSS

   Wix has no full export. Import blog posts from the Wix RSS feed with the RSS importer (Wix's feed shows at most 20 posts), copy pages manually, download images, and build a complete redirect map. Full steps: Wix and Squarespace to WordPress.

   You should see: Recent posts are imported, and older posts and pages are listed for manual copying.
3. 3

   WooCommerce to Shopify

   Where: WP Admin > Products > All Products > Export; then the Store Migration app in your Shopify admin

   Shopify's Store Migration app imports products and customers from WooCommerce CSV files; order history needs a third-party migration app or the Order API. Recreate payment, shipping and tax settings, then redirect product and category URLs. Full steps: WooCommerce to Shopify.

   You should see: Products and customers appear in Shopify (products as drafts), with an import report for each file.
4. 4

   Changing the domain at the same time

   Where: Your project plan, then Google Search Console (Change of Address) once the host move is stable

   Treat it as two changes. Move the host first, confirm stability, then change the domain with 301s and Search Console's Change of Address. Full steps: change domain without losing SEO.

   You should see: The host move is finished and stable before any domain redirects go live.