How to Move WordPress to a New Host Safely

A safe WordPress hosting migration moves three things together: the site files, the database, and the environment that makes them work. The new copy must be tested before public DNS changes, and you need a plan for orders, form submissions, uploads, and account changes created during the final transfer. A homepage that loads is not enough evidence that the migration succeeded.

Quick answer: Create a restorable backup, inventory the current environment, and confirm that the destination supports the required PHP and database versions. Copy the site, test it under its real hostname without changing public DNS, then schedule a controlled cutover. Stop writes on the old site, synchronize the latest database and mutable files, update DNS, and monitor both servers until the previous TTL has expired. If the public domain and path are unchanged, do not run a blanket database search-and-replace.

Identify the migration you are actually performing

Moving to a new host while keeping the same domain is different from changing the domain or URL structure. A busy WooCommerce store adds another constraint: data can be written to the old database while the initial copy is already running on the destination.

• Same domain, new host: public WordPress URLs normally stay unchanged.
• New domain or path: stored URLs may need a serialization-safe replacement.
• Transactional site: orders, inventory, memberships, and form entries require an explicit final synchronization plan.

The official WordPress migration guide likewise treats files and the database as separate required assets and warns against naive replacements in serialized data.

Inventory the source and destination

Record the current stack before copying anything. This turns a vague “the new host behaves differently” problem into a comparison you can diagnose.

• PHP version, memory limits, execution limits, and required extensions
• Web server, rewrite rules, PHP handler, and document root
• MySQL or MariaDB version, character set, collation, and database size
• WordPress core, active theme, plugins, and must-use plugins
• Real cron jobs, background queues, and scheduled tasks
• SMTP, object cache, page cache, CDN, WAF, and external storage
• Disk space, inode availability, uploads size, and growth rate
• DNS records and TTLs for every hostname involved in web traffic

If performance is the reason for moving, compare the evidence with the guide to determining whether hosting is slowing WordPress. A migration carries slow queries and inefficient plugins to the new server unless you address them separately.

Create a backup you can restore

You need a complete database export and a copy of the WordPress files. The application may also depend on web-server configuration, PHP settings, cron definitions, TLS automation, or files outside the document root. Add those dependencies to the migration inventory instead of assuming everything lives under public_html.

Verify archive size and checksums, and test that the backup can be read or restored in an isolated environment. A successful backup job only proves that a process produced a file; it does not prove that the site can be recovered from it. Keep the last known-good backup separate from new migration copies.

Lower DNS TTL before the cutover

Lowering a TTL shortly before changing the record does not invalidate answers already cached under the previous TTL. Apply the lower value at least one old-TTL period before the planned cutover. Where possible, move the website by changing its origin records rather than moving the authoritative nameservers at the same time.

A low TTL still does not guarantee that every client switches instantly. Some resolvers cache longer than expected, and existing connections may remain open. Keep the old host available and watch access logs on both servers. Raise the TTL to its normal operational value after the migration has stabilized.

Prepare the destination without changing public traffic

1. Provision compatible PHP and database versions.
2. Create a dedicated database user with access only to the destination database.
3. Configure the document root, file ownership, PHP handler, and web server.
4. Prepare the virtual host for the real domain.
5. Plan TLS issuance, cron, SMTP, cache, and monitoring.

A hosting migration is already a significant change. Avoid combining it with an unnecessary PHP major-version upgrade, domain change, and web-server replacement. Fewer simultaneous changes produce a clearer rollback path. If the destination uses Nginx, review the WordPress Nginx configuration guide separately.

Copy the files and database

The transfer method depends on your access: a reviewed migration tool, a hosting control panel, SFTP, or SSH can all be appropriate. For a large site, an incremental file copy can reduce the final synchronization window. Treat deletion flags and broad path substitutions as destructive operations; inspect their scope and use a dry run where the tool provides one.

Export the database with a tool compatible with the server version and your privileges. During import, check SQL errors, table counts, encoding, and collation. An “import completed” message is not an application-level integrity test.

Configure wp-config.php for the new environment

Update DB_NAME, DB_USER, DB_PASSWORD, and DB_HOST for the destination. Confirm the table prefix, cache integration, environment constants, and any hard-coded filesystem paths. Never place the database password or the contents of wp-config.php in a public repository, command transcript, or support ticket.

If WordPress displays an Error Establishing a Database Connection, validate the host, listener, credentials, privileges, and table prefix independently. A connection error does not by itself prove database corruption.

Test the destination under the real hostname

Test with the final hostname because cookies, redirects, CORS, TLS, and virtual-host selection depend on it. A temporary hosts-file entry on an authorized test workstation can direct that hostname to the new IP without changing public DNS. A provider preview URL may help, but testing by raw IP is not equivalent to testing the final HTTPS site.

Protect the staging copy from public access and search indexing. A noindex directive is not access control. Prevent the test instance from sending real customer email, processing live payments, firing production webhooks, or running duplicate scheduled jobs.

Run a functional pre-cutover test

• Homepage, posts, archives, search, 404 handling, and permalinks
• Administrator login and logout with a low-privilege test account
• Media rendering, new upload, and thumbnail generation
• Contact forms and email delivery through a controlled recipient
• REST API, loopback requests, Site Health, and WP-Cron
• Page cache, object cache, purge behavior, and excluded dynamic routes
• HTTPS certificate chain, redirects, and mixed-content warnings
• For WooCommerce: cart, tax, shipping, stock, and sandbox payment flow

Read PHP, web-server, database, and queue logs while testing. A page can return HTTP 200 while Ajax calls fail, background jobs stall, or warnings expose a compatibility problem.

Decide whether search-and-replace is necessary

If the domain, scheme, and public path stay the same, changing the server IP does not require a URL replacement in WordPress. An unnecessary replacement can modify email addresses, external identifiers, and plugin data that were never supposed to change.

If the domain or path changes, use a tool that understands PHP serialized data. The official wp search-replace command supports a dry run and handles serialized values:

wp search-replace 'https://old.example' 'https://new.example' --all-tables-with-prefix --dry-run
wp search-replace 'https://old.example' 'https://new.example' --all-tables-with-prefix

Replace the example domains, review the dry-run counts and affected tables, and take a backup before the write. Multisite installations and plugins with custom tables may need a different scope. Do not expand the command to every database table without understanding what else shares that database.

Synchronize final writes before cutover

The old site continues to receive comments, orders, form entries, uploads, and configuration changes after the initial copy. For a low-change content site, use a short maintenance window: stop writes, copy the latest database and mutable files, run a focused verification, then switch traffic.

For a store or membership site, a clear read-only or maintenance period is often safer than trying to merge two independently changing databases. Near-zero downtime requires more than a short DNS TTL; it may require replication, shared storage, compatible sessions, application support for concurrent origins, and a rehearsed cutover.

Switch DNS without overlooking IPv6 or a CDN

Update every record that can send web traffic to an origin. A stale AAAA record can keep IPv6 clients on the old server even after the A record changes. If a CDN or reverse proxy fronts the site, update and verify its origin separately.

Query more than one resolver and compare the answers, but do not treat a single DNS check as proof of worldwide propagation. Access logs on both origins show where real requests are arriving.

Verify SSL from the public edge

The destination must present a certificate valid for the final hostname with a complete chain. Check HTTP-to-HTTPS redirects, WordPress home and site URLs, and proxy headers. With a CDN, browser-to-CDN TLS and CDN-to-origin TLS are separate connections and both need a valid security policy.

Also verify renewal, not just the current certificate file. Copying an existing certificate without recreating its renewal and reload process creates an outage that may not appear until weeks later.

Complete post-migration verification

1. Check DNS, TLS, HTTP status, canonical URLs, and robots directives externally.
2. Repeat login, forms, email, cron, and the site's primary business transaction.
3. Monitor fresh PHP, proxy, database, and queue errors.
4. Purge cache and CDN content selectively, then verify dynamic exclusions.
5. Review analytics, webmaster tools, webhook endpoints, and IP allowlists.
6. Confirm scheduled backups on the destination and plan a restore test.

Do not destroy the old environment as soon as the new homepage loads. Keep it available but prevent new writes until the previous TTL has elapsed and traffic, logs, and business checks show that the destination is stable.

Write the rollback plan before changing DNS

Rollback is not merely pointing DNS back. If the destination has accepted new orders or user changes, returning traffic to the old database can hide or duplicate those records. Define the rollback threshold, decision owner, last synchronization point, and reconciliation method before cutover.

Common WordPress migration mistakes

• Changing DNS before testing the destination
• Copying files without the database, or the database without files
• Using raw SQL replacement that corrupts serialized data
• Shutting down the old origin immediately
• Forgetting an IPv6 record or CDN origin
• Upgrading PHP and changing the domain during the same cutover
• Allowing both copies to run email, cron, webhooks, or payments
• Ignoring orders and uploads created after the initial copy
• Testing only the homepage and not reading application logs

When does a migration need specialist support?

A high-volume store, large database, WordPress Multisite network, custom plugin stack, or strict availability target turns data coordination and rollback into the hardest parts of the move. The WordPress migration service covers destination preparation, controlled transfer, and post-migration checks for those cases.

Frequently asked questions

How long does a WordPress hosting migration take?

It depends on file and database size, transfer speed, destination preparation, testing, and the existing DNS TTL. Include final synchronization and post-cutover observation; the copy duration alone is not the full migration window.

Does changing hosts change the website URL?

No. If the same domain, scheme, and path remain in use, the public URL does not change. DNS or the CDN simply directs that URL to a different origin.

Can changing hosts hurt SEO?

The hosting change itself does not require new URLs. Extended downtime, repeated 5xx responses, incorrect redirects, changed canonicals, blocked crawling, or missing content can affect crawling and users. Verify those signals after cutover.

Is a migration plugin enough?

It may automate the copy for a straightforward site, but it does not remove the need to verify DNS, SSL, email, cron, cache, destination capacity, and data created during the cutover window.