WordPress migration, staging and imports: choosing the right tool

Define what actually needs to move

You are changing hosts, preparing a redesign or moving content into an already built website. These operations do not have the same expected result. A complete migration copies an installation to a destination; staging prepares a working version; a partial import adds or updates certain objects. The tools presented cover these different scopes. Editions and extensions of the same family are grouped together.

Start without a new plugin: ask the host whether transfer or a working copy is already available, with what scope and rollback. Someone with file and database access can also prepare a manual copy. This journey requires understanding server configuration and website addresses; it is not merely copying the media folder.

Content export available under Tools is not a complete installation copy. It addresses moving supported content with an importer at the destination and leaves other elements to handle. The theme, its files, extensions, certain options and external dependencies must be considered separately. For a redesign retaining only posts, this limitation may instead avoid copying an unnecessary old configuration.

These notices concern installations where you can use the necessary tools. On WordPress.com, check plan capabilities and the permitted import or migration journey. In multisite, copying a subsite, the main site and the entire network are three different needs. No universal compatibility is inferred from a general WordPress statement in sales documentation.

Choose between an archive, direct transfer and selected content

A portable archive suits retaining a set of files and data before reinstalling it elsewhere. It requires understanding how to restart import and where to keep the package without public exposure. Direct transfer connects both installations, sometimes through an intermediary service. It depends on access and communications permitted at both ends. Neither is automatically superior.

Repeatable synchronisation can help a team refresh a development copy. Check its direction: pulling data from the live website to a copy differs from pushing the copy to the live website. Define source, destination and included elements before every run. A saved task remains dangerous if these environments have changed roles since its creation.

Content import transfers posts, products or other supported objects without replacing the whole website. You must then decide how to match existing objects, handle duplicates and retrieve media. Object relationships and specific fields require suitable features. A readable CSV does not prove that all relationships will be reconstructed.

Free and paid features vary by journey. An edition may export the website without providing the same import, move a database without files or create staging without allowing its return to the live website. Compare the complete journey before starting. Unestablished prices and renewals remain unknown: do not confuse a trial with lasting free use.

Prepare access and usable rollback

Identify both hosts, authorised access, databases used and volumes to transfer. Check space needed for the website, archives and extraction, along with upload and execution limits. Do not choose a product solely by a size displayed in a slogan. A limit may come from the server, transport or edition; diagnosis must identify which.

Keep a source backup and a destination backup if it already holds useful data. Check how to recover them without depending on the administration you will replace. Define who decides to return to the old host and which changes since copying need preservation. Rollback can also lose recent data if this is not planned.

The domain, mailboxes, certificates and external services need separate checks. A WordPress migration does not demonstrate that email was copied or every network record must be replaced. Retain existing configuration and prepare targeted changes with the domain owner. Verify the destination before presenting it to visitors.

• Explicitly record source, destination and chosen scope before running a tool.
• Prepare an independent backup and means to restore it; do not delete the old installation during checks.
• Stop if the tool proposes overwriting a destination containing unpreserved data.

Preserve data received during the work

An example illustrates the risk: you create a copy on Monday, then the live website receives a new registration or order on Tuesday. If you replace its database on Wednesday with Monday’s, this new data may disappear. The problem does not depend solely on the plugin brand. It comes from copy timing and the scope sent in the opposite direction.

For a simple update test, you can reproduce validated changes on the live website instead of pushing the entire test database. For an editorial redesign or complete migration, prepare a cutover schedule and strategy for new writes with the owner. A temporary write restriction must not be decided by assuming no customer is using the website.

Some products advertise merging or selective synchronisation. Ask which objects are handled, how conflicts are resolved and which components are compatible. Selecting a table is not necessarily selecting a single feature: several data types may be related there. A customised shop deserves examination of its relationships, not a universal table-exclusion list.

A partial import also requires matching checks. Which identifier recognises an existing object? Does rerunning update or recreate it? How are deletion and relationships handled? Examine a small representative set in a protected copy before deciding to transfer the entire collection. These criteria are checks to perform, not trials we claim to have executed.

Isolate staging before any changes

A working copy may retain customers, API keys and external connections from the original website. Protect access and limit personal data to test needs. Preventing appearance in search engines and keeping data confidential are different topics: an indexing instruction does not control who can open the address.

Examine email sending, payments, subscriptions, notifications and connected automation. Test orders may trigger emails or appear real to an integration. Use provided test modes and disable external effects before simulating a journey. A real payment or customer email is not an acceptable way to identify a copy.

Visibly label the environment to avoid window confusion and check the address before any destructive action. A subfolder copy may share server resources; an external copy entrusts data to an additional service. Compare work needs, access rights, retention and cost rather than assuming one destination is always preferable.

Migration keys, archives and installers must remain accessible only to authorised people. After validation, follow the tool-specific cleanup procedure and remove temporary access no longer needed. Keep recovery archives in designated storage without leaving a usable package in a public directory of the new website.

Check the destination, then organise cutover

Start by checking representative content: a post with media, a page using theme features, search and login journey. Examine generated addresses and expected files. A transfer-complete message does not prove external dependencies or every page work. Relate errors to the tool log and destination environment.

For a shop, check useful features on the copy with their test facilities: product, cart, order, simulated payment and specific interactions. Compare data you decided to preserve. Do not replace these checks with merely visiting the homepage. If the destination redirects to the old address or cannot find media, fix that cause before switching visitors.

An address change may require replacing database references. Use a mechanism able to handle the structured data concerned and first examine a dry run where available. Avoid an indiscriminate global replacement in an SQL file: some encoded values contain length information and relationships. Preserve the database before every correction, even after an apparently successful migration.

Finally plan targeted network changes and monitoring with the domain owner. Keep the old installation for the agreed verification period without letting it silently receive data that would then need reconciliation. Check access, certificate and expected tasks after cutover. If the success criterion is not met, apply planned rollback with new data preserved.

Three journeys according to the expected result

For a complete copy, the expected result is a website you can open and administer at the destination. For partial import, it is transferred content without replacing the rest. For staging, it is an isolated copy and a defined means of applying the useful change. Choose only one of these objectives for your first trial: combining all three makes checks and rollback difficult.

The following journeys describe operations to perform on a prepared, backed-up destination. They are not a report of tests performed by our editorial team. Labels may vary with language and version; always examine the summary before an operation writing to the database.

• Content only: on the source, Tools → Export, choose the scope, then download the XML. On a test destination, Tools → Import → WordPress, import the file, map authors and choose attachment retrieval. Check an old post, a recent one, an image and a category. If rendering depends on a builder, check its support before a full import.
• Complete website with access to both administrations: back up the destination, install the same migration family at both ends and export files plus database. With All-in-One, import the .wpress through its Import screen; with UpdraftPlus, upload backup components, then restore them. Do not mix formats. After restoration, log in again with the restored website’s credentials and check the actual address, media and internal links.
• Staging for a change: create the copy, protect access and disable real emails and payments. Reproduce only one change and note affected files or settings. If the free edition does not allow a push, reproduce these verified settings in production or choose the appropriate tier. For an active shop, do not replace the entire database merely to transfer a visual change.
• To stop a trial: keep the source in place, restore only the destination from its backup if no useful new data has arrived there, then correct the scope. If orders or accounts have arrived, preserve them and organise reconciliation before restoration. After a DNS cutover, rollback also requires checking which server now receives writes.

Read commercial terms and maintenance

Prices come from the initial November 3, 2026 record, with a targeted November 10 review of tools cited in the acceptance test and several paid offerings. An equivalent monthly price may require paying a full year. Compare renewal, website or person limits, external services and additional purchases.

Directory compatibility statements remain publisher declarations. The Better Search Replace test described separately concerns only its CLI engine and a local SQLite database; it validates neither its AJAX interface nor a complete MySQL migration. A recent update alone does not ensure support for your WordPress, PHP, shop and builder combination. When a commercial offering is inaccessible or contradictory, its notice says so. For a new critical operation, preferably choose a journey with already established rights, access and recovery.

Test an address change on a destination database

On an isolated copy, note home and siteurl values. In the acceptance test, both pointed to https://origine.example.test. The destination address, https://nouvelle-vitrine.example.test, is longer. The sample page contained a link to école.pdf, and two data structures reused the old address. One was serialised metadata, the other a serialised string inside an option that was itself structured.

Back up the destination database before applying replacement. Under Tools, open Better Search Replace. Enter both complete URLs with their protocol. On an installation with the wp_ prefix, choose wp_posts, wp_postmeta and wp_options for this test set. Keep dry-run mode active and GUID changes disabled. On a real website, extension tables may also contain URLs. Add only those identified.

The dry run found five cells across the three tables, with zero updates. Rereading in a separate process found the same data. Then the Better Search Replace 1.4.11 engine replaced addresses at the destination. The page, home, siteurl and nested structures took the new values. The link to another domain and the content GUID remained identical.

In the sample, replacing the raw string changed the address length without recalculating the length recorded in serialised data. Reading failed. After Better Search Replace processed it, WordPress reread the updated value and the accented document remained correctly referenced. The test verifies the database link. Check the file itself on destination hosting.

• Create a test page and extension datum. Record addresses, value types and a link to retain.
• Run a dry run on the destination, compare the expected total and confirm the prefix before any write.
• Apply on the copy, then reread in a new session. Check links, options and nested data.

Return to the previous copy and choose an alternative

If the new website loses a link, setting or access, avoid multiplying replacements to guess the cause. In the WordPress 7.1.4 acceptance test, rollback restored the SQLite snapshot taken at the destination immediately before the operation. Rereading found original URLs and the same metadata fingerprint. The source retained its data throughout the procedure.

On MySQL or MariaDB, rollback normally uses a consistent export of the destination database. First identify the database into which it will be reimported. If the destination has received real orders or registrations since that export, record them and choose targeted recovery with the data manager. The rollback executed here covers a WordPress CLI engine and isolated SQLite database. It reproduces neither the plugin AJAX interface nor a DNS or hosting change.

If WP-CLI is available, simulate with wp search-replace followed by the old URL, new URL and tables to process, then --skip-columns=guid and --dry-run. Back up the destination. After verification, rerun the same command without --dry-run. If moving only posts or pages, use WXR export and WordPress Importer instead. Keep source media accessible and check what the destination retrieved.

• Distinguish database rollback, file rollback and network-address rollback.
• Check the saved set on a copy before needing it.
• Validate recovery at the destination and check recent content before any public opening.

Further reading

• WordPress images return 404 after migration: repair files and their URLs
• WordPress mixed content: fix HTTP resources on an HTTPS page
• WordPress import: resolve a missing or invalid WXR version