WordPress Website Migration: How to Move Hosting Without Breaking Email or DNS

Plan a WordPress website migration with backups, DNS records, email protection, SSL checks and testing before moving traffic to a new host.

A migration is more than copying WordPress

Moving a WordPress website sounds simple: copy files, export the database and point the domain at a new server. In practice, the website is only one part of the system. DNS may also control Microsoft 365, Google Workspace, subdomains, verification records and third-party services. A technically successful website copy can still cause a business outage if those records are replaced or forgotten. Treat migration as a controlled cutover, not a file-transfer exercise.

Map the environment before your WordPress website migration

Record the current host, WordPress version, PHP version, database details, SSL arrangement and important plugins. Export or photograph the DNS zone before touching nameservers. Identify where email is hosted and whether the website sends mail through SMTP or an external provider. This inventory gives you a baseline when something behaves differently after the move. Our digital continuity checklist provides a useful structure.

Take an independent backup

Create a fresh backup immediately before migration and keep a copy outside both the old and new hosting accounts. Include the database and uploads, plus any configuration files needed for recovery. Do not cancel the old host while the new copy is still being tested. If the migration method fails, the fastest recovery is often to leave production where it is and investigate without a deadline.

Build and test before changing DNS

Where possible, prepare the new site before directing public traffic to it. Check page layouts, images, menus, forms and logged-in functions. Confirm the PHP version and required extensions are compatible. A migration can expose old hard-coded URLs or permissions that were tolerated by the previous server. Our post-migration image guide covers one common symptom.

Protect email during a WordPress website migration

If the domain uses external email, preserve its MX, SPF, DKIM and verification records. Changing nameservers can replace the entire DNS zone, not merely the website address. That is why email may stop even though the new website works. Compare the old and new zones line by line before cutover. For Microsoft 365, see the DNS and MX record guide.

Plan for DNS propagation

DNS changes are cached, so visitors may temporarily reach different servers. Avoid making repeated changes because the first result was not instant. Keep both environments available during the transition and understand the TTL values involved. Our DNS propagation explainer describes why the old server can remain visible after a correct change.

Verify SSL and redirects

Once traffic reaches the new host, confirm HTTPS works for the canonical domain and that HTTP redirects correctly. Check common variants such as www if they are used. Avoid stacking redirects at the registrar, CDN, web server and WordPress level without understanding which layer owns the rule. If browsers show warnings, use the SSL troubleshooting guide rather than disabling HTTPS.

Test your WordPress website migration from the visitor’s perspective

Open the site in a private browser, submit forms, test navigation and inspect several representative pages on mobile. Send an enquiry and verify delivery. Check WordPress admin access and scheduled tasks. Monitor error logs during the first day. If something is wrong after a move, the migration troubleshooting guide helps isolate DNS, cache, URL and server issues.

Retire the old host only after verification

Keep the previous environment long enough to confirm traffic, email and forms are stable. Then archive a final backup and document the new host and DNS ownership. TempWebz provides WordPress hosting migration and technical support for businesses that want the cutover planned without changing the site’s appearance.

Set a WordPress website migration acceptance checklist

Agree on what must work before the new host becomes the normal destination. Include representative pages, media, search, forms and any booking or payment workflow. Record the current URLs so the migration does not accidentally become an unplanned URL change. The official WordPress migration guidance distinguishes moving servers from changing site addresses.

If the domain and public URLs stay the same, avoid unnecessary changes to slugs, menus or canonical settings. If a separate URL change is genuinely required, plan redirects and internal-link updates explicitly. Keep the scope clear so a hosting move does not introduce unrelated search or design problems.

Protect new data during a WordPress website migration

Identify what can change while the copy is in progress. Orders, enquiries, user accounts and content edits may continue on the old site. A copy taken at the start will not contain later records. Agree on a freeze, final synchronisation or another appropriate method with the developer before cutover.

For example, a shop can appear correct on the new server while missing orders placed after the original database export. Recopying the database without a plan may then overwrite new activity on the replacement. Treat data reconciliation as part of the migration, not a final visual check.

Make rollback a specific decision

Record who can approve rollback, which failures trigger it and how the previous service remains available. Keep the old DNS values and a known recovery copy secure. A DNS reversal may still take time to reach different visitors, so do not describe rollback as instantaneous.

Consider how you would preserve any new records created after cutover before returning to the old environment. The right approach depends on the site’s activity and migration method. Ask for a clear explanation before moving a business-critical system.

Close the WordPress website migration carefully

Check the new site from a normal public connection, not only a developer preview. Verify HTTPS, canonical URLs and important redirects. Confirm that any temporary staging access restrictions or noindex settings have not carried into production. Test email and forms separately from page loading.

Once the agreed checks pass, document the new provider, support contact, backup arrangement and any outstanding issue. Retire the old service only with the owner’s approval and after preserving required data. Keep the migration record so future maintenance starts from the correct environment rather than an obsolete hosting account.