How to Change Website Hosts Without Breaking Your Business Email
Your new website is ready. The hosting company says to point the domain at its server. But the same domain handles your invoices, quote requests and password resets. Before you touch DNS, figure out who runs three separate things: your domain registration, the records that direct traffic, and your mailbox service. The answers may all […]
Your new website is ready. The hosting company says to point the domain at its server. But the same domain handles your invoices, quote requests and password resets. Before you touch DNS, figure out who runs three separate things: your domain registration, the records that direct traffic, and your mailbox service. The answers may all be different.
This checklist is for a move where your public URLs and email addresses stay the same. A new domain or a new mailbox provider calls for its own migration plan.
Record what is working now
Ask whoever manages DNS for a zone export or dated copy of the live records. List the nameservers, website records, mail records, and records for subdomains, third-party tools and verification. Identify who controls each service and who can restore the previous settings. Confirm which account pays for the mailbox and whether cancelling the old web package would also cancel email.
| Item | What to record | Why it matters |
|---|---|---|
| Root domain and www | Current A, AAAA, CNAME or provider-specific alias records | These route visitors to the site. An overlooked IPv6 record can send some visitors to the old server. |
| Incoming mail | MX destinations, priorities, and any in-zone hostnames they rely on | Website and mail may share a host. Moving the website can affect mail when records or services depend on it. |
| Sending identity | SPF, active DKIM selectors, DMARC and any provider verification records | Forms, invoices and newsletters may send through different providers. Keep the records those senders need. |
| Other services | Subdomains, CAA records and relevant TXT records | Portals, certificates and analytics verification can have separate dependencies. |
One common trap: the new host asks you to replace nameservers. Changing nameservers hands off the entire zone. If you only need to change the website and your current DNS provider supports it, ask whether updating the necessary web records in place is enough. If the DNS provider must change, recreate and verify the complete zone before switching. Ask the provider to walk you through DNSSEC if it is enabled.
Rehearse the site on the new host
Make a restorable backup of the current database and files. On the new host, check the home page, two money pages, a long article and a missing URL. Test redirects, images and any appointment or checkout process in the appropriate test mode. Ask the host how to verify TLS for the actual domain. Protect a staging copy from public access, then confirm the public site will not inherit the staging site’s indexing restrictions.
Give the new form a separate test using a harmless reference such as MOVE-TEST-01. A success message only confirms what the visitor sees. Confirm that the expected staff mailbox actually receives the notification and that replying reaches the test sender. Check any autoresponder separately.
Watch for mail addresses tied to the old host
Here is a fictional example. The current MX record for a business points to mail.example.com. That hostname has its own A record and is handled by the old hosting plan. The business can update www.example.com to the new site while leaving mail alone, but it cannot safely cancel the old plan until the mailbox is moved or separately retained. If the MX record instead points to the root domain itself, changing the root’s address could change where mail is delivered. Ask the mail provider to confirm the arrangement before any cutover.
Also check whether the contact form uses a mailbox or a sending service on the old server. DNS can be correct while the new website still attempts to send through an obsolete local mail setup. Test an actual form submission after the move. If you change more than one system in the same window, keep a separate checklist for each so the team can locate a failure quickly.
Move during a quiet period and test both directions
- Choose a time when the person who can roll back is available. Save the old record values where that person can find them.
- Make the agreed website DNS change and note the time. Keep the old site and email service running during the transition. If your site takes orders or bookings, agree in advance which copy receives writes during the switch and how to reconcile records.
- Check the live domain on two networks. Verify HTTPS, important pages and the contact form. Send a message into the business mailbox from an outside provider, reply from the business mailbox, and confirm both directions deliver.
- Check Search Console URL Inspection and the site’s canonical URLs, robots settings and sitemap. If the URLs have not changed, follow Google’s guidance for a hosting change without URL changes.
Write down the conditions that trigger rollback. Examples: certificates fail on the real domain, live orders stop arriving, or outside mail cannot reach the business inbox. Reverting DNS may also take time to reach all visitors, which is another reason to keep the old service running until the new one is stable.
Save the zone record, test results and account owners with your vendor handoff checklist. When it is time to cancel the old plan, verify that the cancellation affects only the services you no longer use.