1. Define exactly what is changing

Write down the old environment, destination, domain, protocol, and permalink structure. A hosting change with identical public URLs differs from a domain move or URL restructure. Do not create migration redirects simply because the server changes.

Where possible, separate the move from a redesign, major plugin replacement, or content cleanup. Otherwise, several changes can produce the same symptom, making investigation harder. Name a migration owner and agree who can approve launch, pause work, and authorise recovery.

Confirm access to the registrar, DNS provider, hosting accounts, backups, mail service, and connected applications. A WordPress administrator account alone may not control these systems. Record responsible contacts and verify that recovery access works before the maintenance window, especially when an agency manages part of the setup.

2. Record what must survive

Build an inventory before exporting anything. Include published pages, posts, custom post types, taxonomies, authors, menus, templates, and reusable blocks. Record important unpublished content too. A matching post count does not prove that relationships, layouts, or publication settings survived.

Crawl public URLs and save response codes, titles, canonical addresses, and internal links. Combine this with landing pages from analytics and Search Console. Prioritise enquiry pages, popular articles, campaign destinations, and pages with valuable external links.

List forms, email recipients, CRM connections, scheduled jobs, analytics tags, and external services. Record where media actually lives, including object storage or a separate CDN. Choose representative pages for comparison: a long article, image gallery, landing page, search results, and any custom template.

Save screenshots and expected outcomes for these examples. Document known defects on the old site so they are not confused with migration regressions. Include files linked from newsletters or customer documents, because those addresses may receive valuable traffic even when they are absent from the main navigation.

3. Create a backup you can restore

A complete WordPress recovery needs the database and site files. Include uploads, themes, plugins, and relevant configuration, together with custom plugin tables. Keep the backup outside the environment being replaced, with access limited to the people doing the migration.[1]

The standard WordPress XML export is a content transfer tool, not a complete site backup. It does not package your entire installation, and attachment references are not the media files themselves.[2]

Restore a copy into an isolated environment. Verify login, sample records, attachments, and settings. Record the backup timestamp and restore procedure. An archive that exists but cannot restore the required site is not a usable recovery plan.

Record exclusions explicitly. A host backup might omit an external media bucket, server configuration, or data retained by a third party. Confirm how each dependency will be recovered or reconnected. Keep configuration secrets protected, and avoid placing backup archives in publicly accessible website folders.

4. Rehearse on protected staging

Compare PHP and database compatibility, required extensions, memory limits, file permissions, and rewrite configuration. Check scheduled tasks and any paths embedded in server jobs. Reproduce the production configuration deliberately instead of assuming the new hosting defaults are equivalent.

Protect staging with authentication or access controls. WordPress's search visibility setting is a request to search engines, not a privacy barrier.[3] Prevent the clone from sending real customer messages or triggering production payments and webhooks. Use test credentials and controlled recipients.

Complete a rehearsal using the same migration method planned for launch. Measure how long copying, replacement, verification, and recovery take. This gives the team a practical maintenance window and exposes missing access before the deadline.

Check whether connected services restrict incoming requests by IP address or hostname. The new server may need explicit access even when credentials are unchanged. Review application logs during representative tests, and investigate errors hidden behind a page that appears to load normally.

5. Verify content and replace URLs safely

Confirm the WordPress Address and Site Address match the intended deployment; installations in subdirectories may use different values. Follow WordPress migration guidance for the actual configuration.[4] Check uploads, PDFs, background images, navigation, widgets, and page builder templates after copying.

If stored URLs need replacement, use a tool that understands PHP serialised data. WP-CLI search-replace supports this and provides a dry run. Review the proposed changes, select the intended tables, and take a backup before applying them. Avoid indiscriminate SQL replacements or rewriting GUID values.[5]

Compare records and actual pages. Check author attribution, dates, categories, image alternative text, and downloads. Search rendered pages for the old domain or staging address where neither should remain. Distinguish legitimate external references from internal URLs that need correction.

Inspect content that depends on a plugin or theme: shortcodes, custom fields, dynamic blocks, and custom post types. The database can contain the original text while the frontend loses its intended presentation. Verify that the required component is present, configured, and able to read its migrated data.

6. Test forms beyond the success message

Submit every business critical form using identifiable test data. Exercise required fields, invalid input, conditional sections, uploads, consent controls, and confirmation behaviour. Check domain restrictions on CAPTCHA keys after a domain change.[6]

Verify each expected destination independently. A green confirmation does not prove inbox delivery or CRM creation. WordPress explicitly notes that a successful wp_mail() return value does not establish that the recipient received the message.[7]

Check mail credentials, sender addresses, recipient routing, and your provider's domain authentication settings. Preserve relevant mail DNS records. Test acknowledgements as well as internal alerts, and remove labelled test entries after verification.

Record the submission time and unique reference alongside the evidence from each destination. If an email arrives but the CRM record is absent, investigate that specific connection. Repeat the test on production after cutover, where credentials, anti-spam rules, caching, and network access may differ from staging.

Check uploads with realistic file sizes and types, including any attachments sent by email, because server upload limits and mail provider limits can cause different failure patterns.

7. Preserve search signals and useful destinations

For changed URLs, map each old address to its closest relevant replacement. Use permanent server redirects, normally 301 or 308, for permanent moves.[8] Avoid redirect chains, loops, and sending unrelated deleted pages to the homepage. Content removed without a suitable replacement should return an appropriate 404 or 410.

Check titles, descriptions, canonical tags, structured data, and language annotations where used. Update internal links and the XML sitemap to the final addresses. Keep redirects for at least a year, and longer where users still follow old links. Use Search Console's Change of Address process for supported domain moves, not a simple hosting change.[9]

Inspect production robots rules, page level noindex directives, HTTP headers, and access controls. Remove temporary staging restrictions from pages intended for search while retaining intentional private areas. Google must be able to crawl a page to discover its noindex instruction.[10]

For example, an old installation guide should lead to its replacement guide, not a general services page. Test the destination content as well as the redirect status. A technically valid redirect can still disappoint visitors when it sends them somewhere unrelated to the original link.

8. Control the final copy and DNS switch

Define how new posts, enquiries, registrations, and orders will be handled during cutover. Use an agreed editing pause or a tested final synchronisation process. Two writable copies can collect different records, leaving neither database complete.

If lowering DNS TTL, do it early enough for previously cached values to expire. A lower TTL does not force an instant switch everywhere. Test the new host before updating DNS, then monitor traffic at both environments.[11]

Check certificates, A and AAAA records, CDN routing, and all required hostnames. Preserve MX and TXT records if moving DNS management. During a domain move, old HTTPS addresses still need working certificates to serve redirects.

Take the final consistent backup after the agreed pause, apply the final data copy, and execute the switch. Keep scheduled jobs from running twice. Maintain access to the old environment until verification and reconciliation are complete.

Keeping the old site available does not mean allowing it to accept untracked submissions. Decide whether requests will be paused, routed to one authoritative system, or captured for reconciliation. Explain any interruption clearly to visitors and give the team a way to identify records created during transition.

9. Verify the live customer journey

Test the public site after cutover from a logged out browser and a mobile device. Confirm which server receives the requests. Purge relevant caches, then check navigation, search, downloads, forms, and any checkout or account journeys.

Monitor 404 and server errors, form delivery, and Search Console after launch. Compare traffic with an appropriate baseline; a quiet hour alone does not prove an SEO problem. Search visibility can fluctuate while changed URLs are processed.

Schedule checks immediately after launch, the next business day, and through the following week. Separate missing analytics events from missing visitors by comparing application activity and server evidence. Ask the team receiving enquiries to confirm normal delivery, since a technical dashboard may not reveal operational routing mistakes.