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

A practical WordPress migration guide covering backups, DNS, email, SSL, testing and cutover planning when moving to new hosting.

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 current environment first

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 records during DNS changes

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 from the visitor’s point of view

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.

Practical questions to ask before making changes

Before changing a live business website, write down what you expect the change to achieve and how you will verify it. Know what can be rolled back, where the latest recovery copy is stored and which customer-facing functions need retesting. This simple discipline prevents several unrelated changes being mixed together and makes technical support far more efficient if escalation is needed.

Also consider whether the problem is genuinely inside WordPress. Domain registration, DNS, hosting, SSL, email delivery, local networks and third-party services can all produce symptoms that appear on the website. Checking the right layer first protects a working site from unnecessary modifications.

What should be documented afterwards?

Keep a short record of the date, the original symptom or objective, what was changed and the result. For infrastructure work, note the provider and account that owns the setting. For WordPress work, record significant plugin, theme or PHP changes. Documentation does not need to be complicated; it needs to be understandable to the next person who has to diagnose the site under time pressure.

How to handle WordPress migration without creating a second problem

The safest starting point is to separate observation from action. Record the current behaviour, the relevant account or provider, and any recent change that could be connected. Then decide what evidence would confirm the cause before altering a live setting. Small-business systems overlap: WordPress, hosting, DNS, SSL and email can produce similar symptoms even though the repair belongs in a completely different layer.

Make one meaningful change at a time and keep a recovery path. For WordPress work that normally means a current backup and, for higher-risk work, a staging test. For DNS or email changes it means preserving the existing records before editing them. For hosting changes it means keeping the previous environment available until the replacement has been tested. The objective is not to avoid change. It is to make every change explainable and reversible.

What should be verified afterwards?

Do not stop at the technical control panel. Test the service the way a customer or staff member uses it. Open important pages on a phone and desktop, follow navigation, submit a genuine form, confirm the message arrives, and check any login or download that matters. If email or DNS was involved, test from an unrelated external account. If hosting or PHP changed, review server logs as well as visible pages. A green status indicator proves only what that particular tool measured.

Keep a short change record containing the date, original objective, component changed and result of the verification. This becomes valuable when a problem appears later. Instead of guessing what might have happened, the next person can see what changed and what was known to work immediately afterwards.

When deeper investigation is justified

Escalation is sensible when the same fault returns, the cause crosses several providers, business-critical data is at risk, or the next diagnostic step would require an irreversible change. Repeatedly toggling plugins, rewriting DNS or replacing configuration without evidence can turn a contained fault into a wider outage. Preserve logs and backups, document what has already been tested and avoid making several speculative changes at once.

For a small business, the strongest technical outcome is usually uneventful: the service works, ownership is clear, recovery is documented and future changes can be made without rediscovering the entire environment. That principle matters more than chasing a perfect dashboard score.

A simple review routine for the next 30 days

After the immediate work is complete, schedule one follow-up review rather than assuming the result will remain correct indefinitely. Confirm that the original symptom has not returned, backups have continued, no unexpected administrator or infrastructure changes have appeared, and the customer-facing functions still work. If the work involved email, repeat an external send-and-receive test. If it involved the website, check a representative mobile page and submit a form. If it involved hosting or DNS, confirm the documented provider and records still match the live configuration.

This follow-up is also the right time to remove temporary access, old test accounts, unused staging copies or short-term workarounds created during troubleshooting. Temporary fixes have a habit of becoming permanent infrastructure when nobody records why they exist. Removing them deliberately keeps the environment easier to understand and reduces future maintenance.

Finally, update the business’s technical record with the current domain registrar, DNS provider, host, email platform and recovery contacts. That information may feel administrative while everything works, but during an outage it can save more time than another optimisation plugin. Good technical management is not about making a website complicated. It is about keeping the important parts known, testable and recoverable.