Moving a WordPress site is easier to manage when the new copy is tested before visitors are sent to it. Keep the current site available while you transfer the files and database, check the important features, and prepare a way back if the destination copy has a problem.
The exact steps depend on the host and whether the domain is changing. WordPress's migration guide covers both situations. This checklist focuses on the decisions that help prevent missing content, broken URLs and avoidable downtime.
1. Record what the site depends on
List the site's domain, database, email service, scheduled tasks, SSL setup and external integrations. Note the current PHP and database versions, plus the themes and plugins the site relies on. If the site has a shop or membership area, include the parts that change frequently, such as orders, bookings, new accounts and customer messages.
Also make a note of who manages DNS and email. Moving a website's web records does not automatically move mailboxes or their MX records. Keeping those separate in your plan helps avoid switching one service while expecting another to move with it.
2. Make a complete backup
A typical WordPress site has two parts to protect: its files and its database. The files contain themes, plugins, uploads and configuration; the database contains posts, settings, users and other site data. WordPress's backup guidance explains why both are needed for a complete restore.
Keep a copy somewhere separate from the old hosting account, and confirm you know how to restore it. If possible, restore the backup to a test environment before the migration. A backup that has never been checked is an uncertain rollback plan.
3. Build a test copy at the new host
Copy the files and database to a staging area or temporary address on the destination server. Update the new copy's configuration to use the destination database, then test it without changing the public domain. Check that the destination environment has the PHP version, database service, extensions and storage the site needs.
Keep staging access restricted. Do not send real customer emails or payments from the test site, and make sure it cannot be mistaken for the live site. If you use a temporary hostname, note it so you can search for references to it before launch.
4. Handle URLs carefully
If the domain stays the same, much of the migration can be a copy of files and database followed by the planned DNS switch. If the domain or directory changes, WordPress's migration guide explains how the site address settings affect the front end and admin area.
Avoid a blind search-and-replace across the database. WordPress warns that serialized data can be damaged by replacements that change string lengths. Use a migration-aware method, keep the original backup and review important URLs after the replacement. If the public address changes, plan redirects from the old URLs and check that internal links, canonical URLs and sitemap entries use the new address.
5. Test the parts visitors rely on
Check more than the home page. Open several posts and pages, inspect images, sign in to the admin area and submit contact forms. For a store, test the checkout in its supported sandbox mode. Check that transactional email, scheduled tasks, search and external integrations work on the new environment.
Look for broken permalinks, missing media, mixed-content warnings and errors in the browser console. Also review the staging site's indexing settings so the test copy does not become the public version or appear in search results.
6. Plan the switch and keep a way back
Choose a quiet time for the cutover and decide how you will handle new data created while the test copy is being checked. Sites that accept orders, bookings or comments may need a final database sync or a short content freeze so recent changes are not left behind.
When the destination copy passes its checks, update the domain's DNS records as planned and confirm that the SSL certificate works on the live hostname. Keep the old hosting account available until the new site has been checked on the real domain. If something important fails, follow the rollback plan rather than improvising edits on both copies.
7. Recheck after launch
Test key pages, forms, logins, email and checkout again on the public address. Look for 404 errors, mixed-content warnings and links that still point to a temporary hostname. Confirm that analytics and site monitoring are receiving data, and submit an updated sitemap if the site's URLs changed.
Some migrations are more involved than a standard single WordPress install. Multisite networks, busy shops and custom applications can have additional URL, data and integration requirements. In those cases, ask the host or a WordPress specialist to review the plan before switching.
A migration is complete when the destination site serves the right content and the important workflows work—not simply when the files have finished uploading.
Sources: WordPress's migration guide and WordPress's backup guide.
