WordPress migration checklist: move files, data and domains safely

Define what is moving and who controls the cutover

A WordPress migration moves an existing application and its data. Decide whether you are changing only the hosting server, or also the domain, URL path or HTTPS scheme. Write down the current WordPress and Site Address settings, database connection, upload location and any custom routing. A server move and a domain change require different checks.

Assign one person to approve the final copy and DNS change. Confirm that you can access the old files, export the database, configure the destination and edit the relevant DNS records. Record the existing records before changing them. Choosing a hosting plan does not itself transfer your website; organise the migration with the person responsible for your application.

Create a matched files-and-database backup

Save the WordPress files and a database export as one identifiable backup set. Include uploads, themes, plugins and the configuration needed to reconnect the application. Downloading the WordPress directory alone does not capture a database stored in MySQL or MariaDB. Record when the export was taken and retain a copy away from the server being replaced.

Check the destination PHP version, required extensions, database compatibility and space for both the restored application and temporary archives. Confirm that your backup can be opened and restored into a separate database. Treat credentials in configuration files as secrets, and remove temporary export files from publicly accessible directories once their purpose is complete.

Plan and test a complete hosting restore

Separate a hosting move from a URL change

When the public domain and paths stay the same, the existing application URLs usually remain valid. Update the destination database connection if its host, database name or credentials differ. Test using a method that preserves the intended hostname, such as a local hosts-file override, where your operator supports it; this changes only the test device, not public DNS.

Scroll the table horizontally if needed.

Handle changed URLs without breaking serialized data

Themes and plugins can store structured values containing both text and its length. A plain SQL text replacement can damage that serialized data when an old URL and new URL have different lengths. Use a WordPress-aware migration tool or WP-CLI search-replace if WP-CLI is available, and review its scope before applying a change.

On a restored copy, run a dry run first, inspect the reported tables and preserve a rollback export. WP-CLI provides --dry-run and --skip-columns=guid; WordPress post GUIDs identify content and should not be rewritten as ordinary links. A Multisite command needs deliberate network scope. Check plugin-owned tables and configuration separately instead of replacing every matching string in every database.

Test the destination without triggering live side effects

Open the homepage, a post, search, media, login and the administration area on the destination. Check permalinks, missing assets, HTTPS redirects and application errors. Test forms and store flows using an appropriate test environment. Keep an isolated copy from sending real customer messages, charging payments or firing production webhooks during rehearsal.

For WooCommerce, verify product variations, basket updates, checkout behaviour and the order administration screen. A successful page load is only one test. Compare the destination with a short list of business functions you use, and resolve differences before the final copy. Record any application setting changed for testing so it can be reviewed before launch.

Review WooCommerce hosting and store setup

Protect orders and other writes during DNS cutover

A shop can receive new orders after the rehearsal backup. Plan a controlled pause in writes or an application-specific final synchronization, then create the final consistent copy. Compare the latest order records and payment-provider events with the approved cutover point. Restoring an older database over live store data can discard transactions that happened afterward.

DNS caches can send visitors to different destinations during the transition. Decide which application is authoritative for orders and how late writes will be handled before switching records. Keep the previous environment available for investigation without casually reopening two writable stores. The DNS guide covers record changes; the migration decision also needs a clear owner for application data.

Check DNS records before connecting the destination

Verify launch and define a usable rollback

Repeat the functional checks through public DNS, inspect application errors and review new orders or submissions on the intended destination. If URLs changed, test important old addresses and their redirects. Check indexing settings, canonical URLs and the sitemap so a staging restriction or temporary hostname is not carried into production.

Set the conditions that would justify rollback. For a live shop, reverting DNS alone does not move newly created orders back to the old database. Reconcile new data before returning traffic, and keep a record of the final migration decision. Retire the old installation only after the destination, recovery copy and business records have been verified.

• Final backup set and destination database match the approved cutover.
• Public URLs, HTTPS, forms and store functions work on the destination.
• New orders and submissions are recorded in the intended application.
• Temporary archives and test-only settings have been reviewed.

Compare WordPress destination plans