How to Move a Website Without Interrupting Business Email

You can move a website while leaving its email service in place. First identify where the mailboxes actually run, then preserve their DNS records and active service while changing the website destination. Changing nameservers or cancelling a bundled hosting account needs extra care because either can affect more than the website.

Tell Niwa who hosts your email when you request a WordPress migration. The migration plan should identify the website records that change and the email services that continue. Discuss your website and email arrangement before the domain switch is scheduled.

This guide concerns keeping business email available during a website move. Moving existing messages to a different mailbox provider is a separate job, with its own accounts, data transfer and delivery checks.

Find the service behind the email address

A familiar address such as hello@example.com does not reveal which company hosts it. The domain registrar, DNS provider, website host and mailbox provider can all be different organizations.

Check the mailbox login and billing account. List the users, shared mailboxes, aliases and forwarding routes the business relies on. Confirm which service receives mail and which service sends it.

Also identify the website's sending route. A contact form can use an SMTP account or another email service independently of the staff inbox. The new website needs its own verified configuration for those messages.

WordPress.com's email options illustrate this separation between a website and an email service. Keeping the domain does not automatically keep a mailbox subscription alive.

Save a record of the current DNS setup

Export the DNS zone where possible, or save the full records and settings before anyone makes changes. Keep that record in the project documentation, with access limited to the people handling the migration.

Relevant email records may include MX, TXT records for sender authentication and provider-specific CNAME or service records. Record their names, values and priorities accurately. Do not replace them with generic values from an unrelated tutorial.

Google Workspace's MX documentation explains that MX records direct incoming mail to the mail service. Its published values are for Google Workspace setup. If Google Workspace is already working and you are only moving the website, that is not a reason to change the mailbox destination.

Check any mailbox hostnames that resolve to the old web server. If mail.example.com points there and the old server is being retired, preserving an MX entry that refers to that hostname may still leave a dependency unresolved.

Choose the smallest necessary domain change

If the existing DNS provider can stay, changing the website's A, AAAA or CNAME records may be enough. Use the destination host's actual instructions. Check both the root domain and www, rather than changing one and assuming the other follows automatically.

If you must change nameservers, prepare the replacement DNS zone first. It must contain the records needed by email and every other continuing service, not just the new web server.

Compare the intended zone against the saved original before making the nameserver change. Ask the person handling DNS to identify each deliberate difference. This is easier to review than trying to reconstruct missing mail records after enquiries stop arriving.

The domain continuity guide explains why domain registration and the services behind that address need separate decisions.

Keep the old mailbox service active

Do not cancel the old hosting bundle merely because the new website looks correct. Check whether that bundle supplies mailboxes, forwarding, DNS or the domain itself.

If the business will change mailbox providers as well, create the destination accounts and agree how messages, folders, contacts and access will transfer. Decide who monitors both systems during the handover. A website export is not an email archive.

Avoid treating DNS propagation as a guaranteed instant event. Cloudflare's TTL reference explains DNS caching. Keeping the continuing mail service available is more useful than relying on a single optimistic propagation estimate.

Maintain an alternative contact route while checking the switch. It gives staff somewhere to report a problem without depending on the service being investigated.

Verify sending as well as receiving

Use external accounts to test incoming mail to the main inbox and relevant aliases. Reply to those messages and check delivery to the external inboxes. Test the staff mailbox through the clients the team actually uses, not only through a web login.

If the sending service changes, review SPF and DKIM with that provider. Google's SPF guidance covers authorizing senders; its DKIM guide covers signing outgoing mail. Copying an MX record does not configure every aspect of outbound authentication.

Submit each important website form using a test address. Confirm that the message reaches the right person and that its reply route works. A form success notice proves submission handling, not inbox delivery.

For a booking website, check the actual reservation confirmation separately. For a store, include the order messages the business depends on. Use controlled tests so staff can distinguish them from real customer activity.

Hand over a working arrangement

Record which company now handles the website, DNS and email, plus where staff should report a failure. Keep the saved DNS configuration and test results with the migration record.

Niwa Business includes a WordPress website or migration, hosting, maintenance and adapted AI tools for USD 150. Define the site's email dependencies in the proposal. If you already have WordPress and only need Niwa, the standalone installation guide avoids creating an unnecessary migration project.

A website move is complete for the business only when customers can still reach it and the team can receive and answer their enquiries.