Moving WordPress to a New Hosting Provider

Moving WordPress means more than copying its pages. Plan the website files, database, domain settings and email dependencies before switching to a new hosting provider.

Start here: same domain or a new address?

This guide covers a typical single-site WordPress move. A new hostname, subdirectory, Multisite network, store or membership site needs additional planning. A hosting move with the same public URL usually does not require changing every URL in the database.

Choose the destination PHP/database versions against WordPress and plugin requirements. Identify mail, payment, backup and scheduled-job integrations before creating a test copy. Prevent that copy from sending customer notifications or running production jobs.

1. Back up the complete application

Preserve WordPress files, uploads, themes, plugins, database and configuration. Save the current Apache rules privately. Verify the archives and database export are readable and know how to restore them.

A WordPress XML export contains editorial content, not the complete application. Do not treat it as a substitute for the database and files. On an actively changing site, arrange an application-appropriate consistent final copy and account for all writers.

2. Prepare the new account

Create the required database and restricted database user through the destination’s supported interface. Transfer files into the correct document root, then set the new database connection details privately in wp-config.php. Never publish that file or paste its secrets into support screenshots.

Follow the host’s ownership and permission guidance. Keep credentials separate from the public release archive. Preserve required provider routing rules only after checking their relevance on the new host.

3. Handle URL changes safely

If the URL stays the same, first test without a bulk replacement. If it changes, use a WordPress-aware method that understands serialized data. A raw SQL text replacement can corrupt plugin settings.

Where WP-CLI is available and approved, this example is a dry run on an isolated test copy:

wp search-replace 'https://old-site.example' 'https://new-site.example' --all-tables-with-prefix --skip-columns=guid --dry-run

Expected result: a report of proposed replacements without saving them. Review the tables, counts and backups before any separately authorized real change. Do not remove --dry-run casually, and do not use this single-site example as a Multisite migration recipe.

4. Test with the intended hostname

Check HTTPS, permalinks, media, forms, search, login and authorized database writes. Test plugin functionality and scheduled tasks without sending real customer mail or payments. A hosts-file preview affects your own computer; other visitors still use public DNS.

If the site redirects to the old address, inspect configured home/site URLs and caches before changing DNS. Never leave WordPress’s temporary RELOCATE setting enabled after recovery; it is not a permanent migration solution.

5. Cut over and retain recovery

Synchronize the final changes under the agreed write-control plan, switch only the necessary routing, and monitor errors and external email. Avoid allowing two independent copies to accept orders or edits.

Keep the old site and backups privately recoverable until validation is complete. If the new system has accepted writes, reconcile them before rollback rather than restoring an older database over new customer activity.

Official references

• WordPress: Migrating WordPress
• WP-CLI: search-replace

Documentation checked 2026-10-18. Examples use reserved names and addresses; replace placeholders only for systems you are authorized to manage. Interfaces and included features depend on your provider and account.