Migrating Zoho Mail to Google Workspace: What to Plan

Migrating Zoho Mail to Google Workspace is a project every fast-growing small business runs into eventually: you signed up for Zoho's free or cheapest paid tier when it was just you and a co-founder, and now you need Google's admin tooling, storage or the Workspace apps your team already lives in.

None of your mail is trapped. Zoho supports standards-based export on its paid tiers, and Google Workspace has a built-in path for exactly this move. The order matters more than any single step: verify your domain in Workspace, provision every user and alias, import existing mail over IMAP while Zoho keeps receiving live mail, recreate mailing lists and shared mailboxes, then repoint your domain's MX records last.

Do the MX change out of order — before the import, before the lists are rebuilt — and you don't save time. You lose mail mid-migration instead.

What actually moves automatically — and what doesn't#

Two different things happen when you switch providers, and conflating them is where most migration guides go wrong. One is mail flow — where new incoming mail gets delivered, controlled entirely by your domain's MX records. The other is mail history — everything already sitting in a Zoho mailbox, which has to be copied over separately, because changing MX records does nothing to messages you've already received.

Google Workspace's migration tooling connects to Zoho over IMAP and pulls existing mail into the matching Workspace mailbox, folder structure included. That part is genuinely automatic once it's configured. Almost nothing else is — filters, mailing lists, delegated access, mobile device setups and any app connected to Zoho's servers all live outside the mailbox itself, so an IMAP import doesn't touch them.

• Zoho Groups mailing lists and their membership
• Inbox filters, rules and out-of-office autoresponders
• Shared mailbox and delegate access permissions
• Mobile device profiles configured against Zoho's servers
• Any third-party app or integration pointed at a Zoho API endpoint or SMTP credential

Pre-migration checklist#

Do this work before you touch a single DNS record. The cutover itself is the fast, ten-minute part of this project. This checklist is the part that actually determines whether anyone notices the switch happened.

• Confirm every current Zoho user, alias and mailing list on one list — you'll recreate each one by hand in Workspace
• Check whether your Zoho plan actually has IMAP access before you plan around it
• Verify domain ownership in Google Workspace and provision every user account and alias before importing anything
• Inventory anything connected to Zoho by API, SMTP credential or ActiveSync — CRM sync, calendar tools, a phone's built-in mail app
• Lower the TTL on your domain's MX records a day or two ahead of the planned cutover, so a revert propagates in minutes instead of hours
• If you're on a paid Zoho Mail tier, check your renewal date. Zoho's Mail Lite and Mail Premium plans are annual-only with no monthly option and no stated pro-rated refund for canceling mid-term, so timing the cutover close to renewal avoids paying for months of a subscription you've already left

The migration steps, in the order that avoids losing mail#

1. 1

   Verify your domain in Google Workspace

   Add the TXT or CNAME verification record Google gives you to your DNS zone. This step alone doesn't touch mail delivery — Zoho keeps receiving everything until you change MX records later.

2. 2

   Provision every user and alias

   Create a Workspace account for each person on your Zoho list, matching usernames where you can. Add any alternate addresses each person currently receives mail at as Workspace aliases — these don't come across with the mailbox import.

3. 3

   Confirm IMAP access on the Zoho side

   Google's mailbox import connects to Zoho over IMAP. If any account is on Zoho's Free plan, verify IMAP is actually enabled before you configure anything — newly signed-up Free accounts don't get it by default.

4. 4

   Run the mailbox import while Zoho stays live

   Use Google Workspace's data migration service to pull existing mail into each new Workspace mailbox over IMAP. Zoho keeps receiving new mail during this window, so nothing sent mid-import is lost — you import the remainder in a follow-up pass.

5. 5

   Recreate mailing lists and shared mailboxes

   Zoho Groups and any shared-mailbox delegate access have to be rebuilt by hand as Google Groups, with membership and moderation settings matched manually. None of this rides along with the mail.

6. 6

   Update SPF and publish DKIM for Workspace

   Add Google's mail servers to your SPF record and publish the Workspace DKIM key in DNS alongside — not instead of — Zoho's existing records. Both can coexist until cutover.

7. 7

   Lower TTL, then switch MX records

   With everyone provisioned, mail imported and lists rebuilt, point your domain's MX records at Google's mail servers. Watch delivery on both sides during the DNS propagation window before touching anything on the Zoho side.

8. 8

   Confirm delivery, then clean up DMARC and old records

   Once new mail is consistently arriving in Workspace, tighten your DMARC policy if needed and remove the now-unused Zoho entries from SPF — but not the Zoho account itself yet.

What the MX record change actually looks like#

This is the part people picture as complicated and it's actually the shortest step in the whole project — the DNS record itself is a couple of lines. What makes it feel risky is that it's also the only step where a typo can misdirect live mail, so it's worth seeing the shape of the change before you're staring at your registrar's edit screen.

Copy the exact values from each vendor's own current setup page rather than from any third-party example, this one included — mail-server hostnames and recommended priorities do change.

What breaks when you move off Zoho#

This is the table most migration checklists skip, because none of these items show up until someone notices they're gone. Verify each row against both vendors' current admin docs — the exact settings screen moves more often than the underlying limitation does.

Rollback plan#

MX records are the easy part to reverse — that's exactly why you lowered the TTL before cutover. If new mail isn't landing correctly in Workspace, or something in the recreated Groups and delegate permissions is broken, pointing MX back at Zoho takes effect as fast as your TTL allows, and mail resumes flowing through the old system.

What you can't reverse is data. Keep the Zoho subscription active and don't delete any mailbox until Workspace has run as the live system through at least one full business cycle with nothing bouncing. The mailbox import can be re-run if you catch a problem early. Deleted Zoho mail can't be re-imported from a mailbox that no longer exists.

Doing it without downtime#

"Downtime" in this migration almost never means mail stops delivering outright — MX changes propagate, they don't create an outage on their own. The real risk is a message arriving during the propagation window and landing on whichever server the sender's resolver still has cached.

That's why the checklist above front-loads the mailbox import: by the time you touch MX records, both systems already hold most of the same history, so it barely matters which one catches a stray message. Pick a pilot group of a few users — not the whole company — and run the full sequence for them first.

Watch for one specific edge case during the pilot: if you forward mail from the new Workspace mailbox back to Zoho (or the reverse) as a safety net, a message that lands during the propagation window can arrive at both, and the pilot user sees a duplicate. That's a forwarding-loop symptom, not a lost-mail symptom — turn off the forward once you've confirmed delivery instead of leaving it running through cutover.

• Import mail before you touch MX records, not after
• Keep Zoho's MX entry as a low-priority secondary during the propagation window if your DNS provider supports it
• Migrate a pilot group first and watch their delivery for a few days before cutting over everyone else
• Cut the wider company over during a low-traffic window — an evening or a weekend, not mid-Monday

Where AI Emaily fits once mail lands in Workspace#

Once your mail actually lives in Workspace, the migration project ends and the daily grind starts again — a fresh inbox that still fills with cold pitches, meeting logistics and threads that need a decision. AI Emaily connects to Gmail, along with Outlook, iCloud and anything else you run, over the provider's own API, so switching your mail host doesn't mean switching how it gets triaged.

It drafts replies in your voice from a Personal Context brain and per-client profiles you set yourself, files mail against rules you can read, and holds every send for your approval until you decide to loosen that — with undo and a full audit trail either way. We build AI Emaily. It's a 7-day free trial on Pro and Autopilot, card required, nothing charged if you cancel before day seven.