How to Move Your Wix Website Without Losing Business Email

1. Separate the four services before changing anything

Website hosting serves your pages, images and forms. Domain registration is the renewable right to use your domain name. DNS is the directory that directs that name to your website, email and other services. Email hosting stores mailboxes and handles sending and receiving. One company may bill you for several of these, but they are different services.

For example, a business might register its domain at Wix, use Wix nameservers for DNS, host its website at Wix and use Google Workspace for mail billed through Wix. Rebuilding the site elsewhere does not by itself move the registration, DNS zone, mailboxes or Workspace billing. Avoid combining all of those changes into a single cutover unless there is a clear reason and a tested plan.

Often the smallest website move keeps the registrar and authoritative DNS provider in place and changes only the required web records. First confirm that the current DNS service can remain available after the website subscription changes. If it cannot, plan a separate full-zone DNS migration before cancelling anything.

2. Identify the accounts and people you will need

Create an inventory with columns for service, provider, account owner, renewal date and recovery method. Confirm you can sign in using an owner-approved account and complete two-factor authentication. Keep credentials in a password manager, not in the migration worksheet or an email quote request.

Check the registrar dashboard and invoices to identify domain registration. Check the domain's nameservers to identify authoritative DNS, then open that provider's DNS dashboard. A registrar is not necessarily the DNS host. MX records suggest the receiving mail platform, but the mailbox admin console and invoices establish the actual mail service and billing relationship.

1. Record the domain, registrar, current nameservers, web host, email platform and any reseller. Include aliases, forwarding rules and website services that send mail.
2. As a read-only cross-check, run nslookup -type=NS yourdomain.example and nslookup -type=MX yourdomain.example, replacing the example domain with yours. Compare the responses with the dashboards. Public lookups can be cached and do not expose the full DNS zone.
3. List integrations: contact forms, booking tools, payments, newsletters, analytics, Search Console and verification records. Assign an owner for launch approval and an alternative contact method if business email fails.

3. Back up the complete DNS zone and mail configuration

Export the DNS zone if the provider supports it, and save dated screenshots as a second reference. For every record capture its name, type, value, TTL and priority where relevant. Record root and www web records, subdomains, verification records, CAA records and mail-related records. Public DNS queries alone cannot enumerate every record or DKIM selector.

MX records route incoming email: preserve every required target and priority from your actual provider. SPF is normally a TXT record authorizing senders; preserve the complete existing value and do not create a second SPF policy at the same hostname. DKIM uses provider-specific selectors, often TXT or CNAME records under selector._domainkey. Find selectors in the email admin console and zone, not by guessing. DMARC is typically a TXT record at _dmarc; preserve its policy and reporting destinations. Save any autodiscover and other mail-service records too.

Copy values carefully: some DNS dashboards automatically append the domain, while others expect a full hostname. Long TXT values may be displayed in quoted chunks. Compare the effective published value after entry. Do not replace working mail settings with generic records copied from an article, and do not change authentication policies as part of a routine website move.

Back up website content, media, contact submissions and business data using the available Wix tools. Separately confirm mailbox retention and backup options with the email provider if needed. A DNS export is not a mailbox backup, and restoring DNS cannot recover deleted messages or a cancelled mailbox.

4. Check Wix and Google Workspace billing dependencies

Review website plans, domain renewals, business email subscriptions and paid apps separately in Wix and the relevant provider accounts. Confirm whether Google Workspace is billed directly or through Wix. Do not assume stopping a website plan transfers email billing, and do not cancel business email merely because the website has moved.

If you want to change the Workspace reseller or billing arrangement, ask Wix and Google about the supported transfer procedure, timing and account access before doing it. Keep the subscription active while the provider confirms the transition. This is different from copying DNS records and different again from moving mailbox data to another email platform.

Keep the old website plan and required DNS, domain and email services active through launch and an agreed observation period. Record renewal dates so that a planned cancellation does not unexpectedly interrupt a service you still need. Ask the provider about any dependency you cannot verify before proceeding.

5. Build and test the replacement before cutover

Prepare the new site on a staging address. Wix layouts and apps may need rebuilding rather than a one-click export. Inventory every public URL, page title, meta description, heading, image and download. Keep existing URL paths where practical; map each changed path to its closest equivalent using a permanent redirect. Avoid sending every old URL to the homepage.

Keep staging out of search results using access protection where possible and appropriate noindex settings. Remember to remove production-blocking protection and noindex directives at launch. Check canonical URLs, sitemap entries, robots rules, HTTPS and redirects between www and the root domain. Preserve important page content and internal links; migration does not guarantee stable rankings.

Rebuild forms and test actual delivery to the intended mailbox, including spam folders, acknowledgments and error states. Use a sender supported by your form provider and a visitor address as Reply-To where appropriate; impersonating the visitor in From can fail authentication. Do not quietly add or replace SPF/DKIM records without reviewing existing senders.

Carry across the existing analytics property and agreed conversion events without installing duplicate tags. Verify page views and test events with the site's consent behavior. On a phone, test navigation, tap-to-call, form labels, validation, attachments if supported and the entire inquiry flow.

6. Make a controlled change and verify both mail and web

Choose a quiet period and write down the exact old and new values before saving. If your provider supports lowering TTL, do so in advance and allow the previous TTL to expire. This can reduce some caching delays but cannot make propagation instant or eliminate downtime.

1. Follow the new host's domain instructions. If authoritative DNS stays in place, change only the required website A, AAAA or CNAME records. Check for stale IPv6 records that could still send some visitors to the old site. Do not delete MX or mail TXT/CNAME records to make room for web records.
2. If nameservers must change, pre-create the complete zone at the new DNS provider and verify its answers first. Coordinate DNSSEC and any registrar DS record with the providers; an incorrect DS relationship can break domain resolution. Do not make an unplanned nameserver switch during launch.
3. Check the root domain and www over HTTPS from more than one network. Confirm key pages, redirects, downloads, forms and analytics. Allow for different cached answers during the transition.
4. Compare published MX, SPF, DKIM and DMARC with the backup. Send mail from the business mailbox to an external account, reply from that account and send a fresh inbound message. Check aliases, forwarding, spam folders and message headers for expected authentication results. A successful outbound test alone does not prove inbound delivery works.
5. Submit a real test inquiry from the new website and confirm receipt, reply handling and any stored submission. Record timestamps and results. Check Search Console and monitor errors and inquiries after launch before retiring the old site.

7. Decide your rollback triggers before launch

Keep a written change log, the prior DNS zone, access to the old host and a named decision-maker. Agree to pause or roll back for failures such as a critical form not delivering, mail not arriving or the primary site failing to load. Troubleshoot against the saved values rather than making a series of unrecorded DNS edits.

For a web-record-only move, rollback generally means restoring the previous web values while the old site remains active. A nameserver rollback is more complex and must consider the full zone and DNSSEC. Cached answers can persist after either action, so restoring a record is not an instant recovery guarantee. Mailbox cancellation cannot be reversed by changing web DNS.

If ownership, billing, DNSSEC or email records remain unclear, stop before cutover and resolve them with the provider. A small, documented move with tested recovery steps is more useful than a promise of zero risk.