Changing website hosts without disrupting business email

Write down what is moving and what is staying

A website move can be quite focused: copy the site to a new server, test it and change the records that direct web visitors there. It becomes a different project if you also change nameservers, transfer the domain or move mailboxes.

Ask everyone involved to agree on a one-sentence scope. For example: “We are moving the WordPress website, keeping Microsoft 365 email and leaving DNS with its current provider.” This is a hypothetical brief, not a recommendation for a particular platform.

That sentence is helpful only after the setup has been checked. An invoice labelled “hosting” may include mailboxes, DNS or other services. A provider’s name on an old document does not prove it still operates the live service.

Make an inventory of the domain registrar, DNS provider, website host, mailbox provider and website email-sending service. Include the account owner and an authorised contact for each. Don’t put passwords in the inventory.

Understand the two DNS changes that are often confused

DNS records tell internet services where to find different things associated with your domain. The records used for the website and the records used for email have different jobs.

A change to the website’s address records is different from replacing the domain’s nameservers. Changing nameservers moves responsibility for answering DNS queries to another DNS service. That means the new service needs the complete relevant record set, not just the website address.

Cloudflare’s email-record guidance explains the role of MX records for mail routing and authentication records such as SPF, DKIM and DMARC. Exact values depend on the email provider. Copying a generic example is not a safe substitute for the records your business needs.

If a nameserver change is necessary, have the technical team compare the old and new DNS zones before the switch. Include relevant subdomains and verification records, not merely the entries that look familiar.

Look for email dependencies hiding in the old hosting account

Even when staff use a separate mailbox platform, the old web server might still send website notifications. It might also host a mail subdomain, a forwarding address or a forgotten mailbox used by an integration.

Ask these questions before cancelling anything:

• Where do staff mailboxes, shared inboxes and aliases live?
• Does the website send through the hosting server or a separate authenticated service?
• Are contact-form notifications, password resets and order emails using the same sending route?
• Does any mail-related hostname point to the old server?
• Are there forwarding rules or automated tasks in the old control panel?
• Will cancelling the hosting package also remove DNS service or mailbox access?

Include devices and systems that send as your domain, such as an invoicing platform or office scanner. The website project may not change those systems directly, but replacing DNS records without understanding them can affect their sending arrangements.

The person responsible for email should review the plan. A website developer cannot reliably infer every mailbox dependency from the public homepage.

Prepare a cutover plan with a way back

Choose a change window when the relevant technical contacts are available and the business can check results. “Late Friday so nobody notices” is not a useful plan if nobody can investigate on Saturday.

Record the existing DNS settings and the intended changes. Confirm access to both the current and proposed services. If the technical team plans to lower record cache lifetimes before the move, allow for existing cached values rather than assuming the new setting takes effect everywhere immediately.

Keep the old website service available for an agreed overlap period. For sites accepting orders or account changes, plan how to prevent different visitors writing new information to different copies during the transition. That data-consistency problem needs its own decision.

Also define the rollback conditions. Who decides to reverse the website change, and which exact records would be restored? A rollback should address the failed part without accidentally undoing unrelated email settings.

If DNS security settings are in use, have the DNS administrator include them in the migration plan. Don’t improvise security-related changes during a rushed cutover.

Test email in both directions

Opening the new website confirms very little about email. Build a small test matrix and record the time of each test, the sending address, the destination and the result.

1. Send from an external account to a normal business mailbox.
2. Reply from the business mailbox to the external account.
3. Repeat for an important shared inbox or alias.
4. Submit a labelled test through the website enquiry form.
5. Test relevant website-generated messages, such as a password reset, using an authorised test account.
6. Check the receiving inbox, spam or quarantine area, and available sending logs if anything is missing.

Use test data, not a real customer’s details. Where possible, include more than one external mail service, since delivery to a single destination does not prove delivery everywhere.

Have the email administrator inspect authentication results for website-generated messages. A changed sending server can need different configuration even when the visible From address stays the same. A successful form submission is not proof that its notification reached the recipient.

If mailboxes are moving too, separate the workstreams

A mailbox migration involves more than pointing email at a different destination. Existing messages, folders, shared mailbox permissions, aliases and staff device settings may all need attention.

Document that as a separate scope with its own acceptance checks. Decide how historical mail will be transferred, what happens to messages arriving during the change and who helps staff reconnect. The details depend on the source and destination platforms.

Do not cancel the old mailbox service just because new messages arrive successfully. First confirm that the required historical information and access arrangements are available in the destination, and that any remaining migration steps are complete.

Where practical, keeping the website move and mailbox move distinct makes troubleshooting easier. If both must happen together, the plan should still show which person owns each part and how failures will be isolated.

Close the move with evidence

Finish with a short sign-off record showing the website tests, inbound and outbound email tests, form notification results and any exceptions. Confirm the new account details are documented and the old service’s cancellation dependencies have been reviewed.

A successful migration is a business outcome: customers can visit, staff can communicate and important website messages still arrive. It is not simply a new server displaying the homepage.

When discussing website hosting and maintenance, explain your current email setup and ask which migration responsibilities are included. That gives everyone a clearer brief before any records change.