Migrating WordPress to another host

Updated · 31 Aug 2026

Short answer.

A reliable migration preserves more than files and a database: addresses, recent data, mail, cron, TLS, integrations, and search signals must continue to work. Verify the new environment before traffic moves, synchronize the final delta, and only then switch.

Check first

Evidence before change.

• DNS, domain, certificate, CDN, and actual mail recipients.
• PHP/database versions, extensions, limits, cron, object cache, and web-server rules.
• Database/uploads size and how quickly they change.
• Absolute URLs in the database, code, CSS, and external integrations.
• Critical forms, payments, webhooks, APIs, and background jobs.
• Current sitemap, robots, canonical, redirects, and important HTTP statuses.

Safe sequence

Move in small verifiable steps.

• Build the inventory. Do not copy until every dependent service is known.
• Prepare the new environment. Block indexing and real side effects while testing the actual configuration.
• Compare behavior. Pages, files, forms, mail, jobs, and headers must behave as expected.
• Agree a freeze or delta. New orders and enquiries between copy and cutover must not disappear.
• Switch DNS. Observe both environments, repeat postflight, and retain the old host through the rollback window.

Common mistakes

What usually increases risk.

• Changing the URL structure during a hosting move without a separate redirect map.
• Forgetting domain mail and SPF/DKIM/DMARC records.
• Allowing real webhooks and mail from the test environment.
• Deleting the old host after one successful home-page load.

320px Site Audit

What can be checked automatically.

Site Audit records an observable pre-migration baseline and helps compare WordPress, technical SEO, and page responses afterwards. It cannot replace DNS, external-mail, or cutover-delta control.

When help is useful

A concrete next step.

For a checkpointed move with URL verification and postflight, see WordPress recovery and migration.