On this page
A WordPress migration moves a working service, not just a folder of pages. The files, database, configuration, domain routing, and external connections must agree about where the site lives. A successful copy can still lose recent orders, redirect visitors to the old domain, or leave a form sending data to the wrong environment.
Define the move before choosing a tool. Changing hosts while keeping every public URL is different from changing a domain or reorganizing paths. Combining those changes is possible, but it creates more questions to verify. Keep the intended outcome and the rollback route clear enough that another responsible person could follow them.
Separate the kinds of change involved
List whether the host, domain, URL paths, HTTPS handling, PHP version, theme, or plugin set will change. Avoid silently adding a redesign or a large software upgrade to a move whose immediate purpose is changing hosting. Each extra change makes a failure harder to attribute.
For a host-only move, preserving the same URLs reduces the need for content redirects, but the new server still needs the correct site configuration and certificates. For a domain or path change, build a mapping from important old addresses to their relevant new destinations.
Google's site-move guidance addresses the URL-changing case. It does not promise an instant transfer of search behavior. Use it to plan the technical signals and monitoring, while keeping the separate task of making the site function correctly at the destination.
Inventory the parts outside the WordPress folder
Identify the database, uploaded media, custom code, server rules, scheduled jobs, mail delivery, payment connections, webhooks, storage services, and any content delivery network. Some of these may be configured in the hosting panel rather than in WordPress.
Check where DNS and domain registration are managed, and who can make the required changes. Moving website hosting does not necessarily mean moving email hosting. Preserve the records and services that are outside the intended move unless the plan explicitly includes them.
Keep credentials in the appropriate secure system. The migration record should identify the owner and access route without becoming a document full of passwords. Confirm that the people performing the move have the access needed for both deployment and recovery.
Prepare and test the destination before switching traffic
Confirm the destination's supported PHP version, required extensions, database compatibility, storage, and web-server behavior. Install the intended files and data using the host's or migration tool's supported method. Record any configuration that must differ between the old and new environments.
Use an appropriate preview method to inspect the destination while the public site remains on the old host. Make sure the preview reaches the new server and still exercises the intended hostname behavior where relevant. A temporary preview address can behave differently for cookies, redirects, or external callbacks.
Protect the destination while it contains a copied site. Apply the same isolation thinking used for staging, especially if the copy can send email, process payments, or run scheduled integrations before traffic is switched.
Decide how to handle changes made during the move
The first database copy is a snapshot. A live site can receive new submissions, orders, account changes, or editorial work after that snapshot. Decide how the final current state will reach the destination and whether a controlled period of restricted writes is needed.
The answer depends on the site and migration method. A quiet publishing site may be able to pause editing briefly. A busy transactional service may need a more specialized synchronization and cutover plan. Do not assume that copying the database a second time is harmless if the destination has already accepted new activity.
Define a clear point at which one environment becomes the authoritative place for new writes. If both copies accept independent transactions during the transition, reconciliation can become difficult. The plan should make that possibility visible before the move begins.
Update addresses with a WordPress-aware process
When the public domain or path changes, URLs may appear in content, settings, menus, widgets, and plugin-managed values. Some stored data is serialized, so a plain text replacement can corrupt values when string lengths change.
Use a supported migration process or a WordPress-aware tool. WP-CLI's search-and-replace command offers serialized-data handling and a dry-run option. Read the current options, scope the operation to the intended installation, and inspect the proposed change before applying it.
Afterward, check the rendered destination rather than only the database replacement count. Look for images, forms, canonical links, redirects, and application callbacks still pointing to the old address. A high replacement count does not establish that every relevant location was handled correctly.
Verify the important tasks on the destination
Choose representative public pages and the actions that make the site useful. Sign in with the relevant roles, save and reopen content, submit a controlled form, and test a transaction through the provider's supported test arrangement where applicable.
Inspect media, permalinks, search, archives, and any custom routes. Check a narrow layout as well as a wider screen if the move changes asset delivery or optimization. Verify mail and external handoffs through the intended test or production-safe process, rather than assuming a visible success message means delivery occurred.
Record the destination evidence separately from the old site's behavior. It is easy to open a familiar URL and accidentally inspect the server that has not yet been replaced. Confirm which environment handled the request before marking a check complete.
Switch routing through a controlled cutover
Carry out the planned final data synchronization and routing change. DNS behavior depends on cached records and the actual configuration, so avoid promising that every visitor will switch at one exact moment. Keep the old environment available for the agreed recovery and transition period.
Verify the certificate and redirect behavior for the intended hostname variants. Check that HTTP and alternate hostnames reach the correct secure destination without loops. If a proxy or content delivery network is involved, confirm that its origin points to the new service and that cached content does not hide a routing error.
Do not remove unrelated DNS records during a website move. Email, verification, and other services may depend on them. Make each change correspond to the documented plan and retain the prior values needed for recovery.
Preserve useful old URLs when addresses change
Map an old article to its corresponding new article where an equivalent exists. Avoid sending every old URL to the home page simply because it is easy to configure. A visitor following a specific link expects the relevant content or a clear explanation of what happened to it.
Use the appropriate permanent redirect for a permanent move and avoid unnecessary redirect chains. Update internal links, canonical references, and sitemaps so the new site describes its own current addresses consistently. Follow the relevant Search Console procedures where they apply to the kind of move being made.
These signals support discovery and interpretation of the move; they do not guarantee a ranking or a completion date. Monitor important old and new routes and investigate actual errors rather than treating every short-term traffic change as proof that one setting is wrong.
Keep rollback compatible with the data state
Identify what would trigger rollback and what it would restore. If the new environment has accepted orders or other writes, switching traffic back to an older database can create data loss or conflicting records. The recovery plan must account for that activity.
Use the backup and restore guide to confirm the available recovery point and restoration method. A rollback decision should restore a coherent service, not merely the server that was familiar before the move.
After cutover, verify critical tasks again through the public route. Retain the migration record, resolve any remaining errors, and retire the old environment only after its remaining responsibilities are understood. The move is operationally complete when visitors and staff can use the destination, current data is accounted for, and the old service is no longer carrying an unnoticed dependency.
Sources and further reading
Primary and contextual sources used to verify definitions or give readers a relevant next resource.
- WordPress: Migrating WordPress WordPress migration requires coordinated handling of files, the database, configuration, and URLs.
- WP-CLI: Search and replace A WordPress-aware replacement process can handle serialized values and preview changes with a dry run.
- Google Search Central: Site moves with URL changes URL-changing moves require mapping, appropriate redirects, updated references, and monitoring as search systems process the move.