How to Migrate from Google Workspace to Zoho Mail

This is a guide for how to migrate from Google Workspace to Zoho Mail as a company — every user, every mailbox, one custom domain. It is written in the order that keeps mail flowing throughout: provision users first, run the mail migration with both providers live, then switch DNS last. Nothing that costs mail is done until the piece before it is verified.

The work splits cleanly. Two hours of admin setup in Zoho, a batch migration run that finishes overnight for most companies and over a weekend for the biggest, a DNS cutover during a quiet window, and a two-week overlap where Google Workspace still catches anything the switchover missed. The whole thing is reversible until you cancel Google Workspace or delete the Gmail accounts.

What actually moves and what doesn't#

Zoho's Google Workspace migration copies mail, and mail only, through IMAP. Everything else — calendars, contacts, shared drives, groups, filters, forwarders — is either a separate export or does not come along at all. The single biggest source of surprise after cutover is a team that assumed Google Calendar and Google Drive rode along with the mail. They do not.

Pre-migration checklist#

Every item here is faster to do before the migration than to reconstruct from a support ticket during it. Work through the list in order and only start the migration when every box is ticked.

• Sign up for a Zoho Mail plan sized for your organisation and add your custom domain in Zoho Admin → Domains. Zoho's packaging is per-seat with a limited free tier for very small teams; check the current per-user price and storage caps on zoho.com before you commit.
• Verify domain ownership with the TXT record Zoho gives you. This has to be in place before you can create users, but it does not affect mail delivery yet.
• Pre-create every user account in Zoho Admin → Users. Match Google Workspace usernames exactly — @yourdomain.com must map to @yourdomain.com — or the migration will not find a target mailbox.
• Note the storage each Google Workspace user is using (Admin console → Reports → Storage). Compare with the Zoho plan's per-user cap. Heavy users occasionally exceed the smaller Zoho tiers and are easier to upgrade before the copy than mid-way through.
• Generate migration credentials. Two options: a Google Cloud service account with domain-wide delegation for OAuth-based migration (cleanest for large tenants), or IMAP with per-user app passwords generated after enabling two-step verification (simpler for small tenants).
• Screenshot your current DNS record set. MX, SPF (typically include:_spf.google.com), DKIM (google._domainkey), DMARC. You want the exact values written down before you touch anything.
• Warn users. Tell them the switchover date, which client to reinstall, and that the first days on Zoho will feel emptier because filters and labels are being rebuilt. A five-line email an hour before cutover prevents half the tickets.
• Do not cancel Google Workspace yet. Downgrade only after the migration is complete, verified, and the overlap window has closed.

The steps in order#

1. 1

   Add the domain and pre-create every user in Zoho

   In Zoho Admin, add your domain, verify ownership with the TXT record, then create every mailbox that exists in Google Workspace. Use the CSV bulk-import (Users → Import Users) for anything over ten accounts. Do not enable Zoho's MX records yet — the domain is verified but mail still routes to Google.

2. 2

   Prepare Google Workspace for migration access

   For OAuth migration: in Google Cloud Console, create a service account, enable Gmail API access, generate a JSON key, and grant domain-wide delegation to the required OAuth scope. For IMAP migration: enable IMAP org-wide in Google Admin, and either have each user create an app password or use the service account.

3. 3

   Configure the Zoho migration profile

   Open Zoho Admin → Mail Administration → Migration → Add Migration. Choose Google Workspace / G Suite as the source. Paste the service-account JSON (OAuth path) or configure IMAP host imap.gmail.com:993 with SSL. Set concurrent connections — start conservative (10–20) and raise if Google is not rate-limiting.

4. 4

   Add users to the migration batch and start it

   Add users individually or in bulk. Zoho lets you exclude folders (Spam, Trash) and set a date range if you only want the last N years. Start with a pilot batch of 3–5 mailboxes, verify the copy on those, then release the full run. The dashboard shows per-user progress.

5. 5

   Migrate contacts and calendars separately

   Contacts: each user exports Google Contacts as vCard, then imports at mail.zoho.com → Contacts → Import. Calendar: each user exports Google Calendar as ICS from calendar.google.com/settings, then imports at calendar.zoho.com → Settings → Import. For large orgs, script this via the Zoho API rather than asking every user.

6. 6

   Verify sample mailboxes before touching DNS

   Open five representative accounts in Zoho — a heavy user, a light user, a shared inbox, a role account, an executive. Confirm folder counts roughly match Gmail label counts, that Sent has the right threads, that a search for a known old message returns it. Only proceed to DNS after this check.

7. 7

   Cut over MX, SPF, DKIM and DMARC

   In your DNS provider, replace Google's MX records with Zoho's regional MX set (for zoho.com global: mx.zoho.com priority 10, mx2.zoho.com 20, mx3.zoho.com 50; regional variants for .eu, .in, .com.au, .jp). Update SPF to include the Zoho include Zoho gives you. Add the DKIM CNAME/TXT record from Zoho Admin → Email Configuration → DKIM. Keep DMARC at p=none until you have watched the aggregate reports for a week.

8. 8

   Enable Gmail forwarding as a two-week safety net

   Even with MX flipped, some senders cache the old MX for a day or two. In Google Admin → Apps → Gmail → Routing, set a default routing rule that forwards all inbound mail to the corresponding @yourdomain address at Zoho. Keep the Google mailboxes accessible; do not disable users yet.

9. 9

   Rebuild filters, groups and aliases

   Recreate any Gmail filter that was carrying operational weight in Zoho's Settings → Filters. Rebuild Google Groups as Zoho Groups (Admin → Groups). Recreate send-as aliases and shared-inbox delegation. This is the tedious hour that everyone underestimates.

10. 10

    Wind Google Workspace down, do not delete it

    After two clean weeks with no user complaints and no useful mail arriving via the forwarder, downgrade Google Workspace to the cheapest tier and archive the accounts. Keep it alive for at least 30 days after the last forward-caught message — deletion is irreversible and breaks Drive links in old mail.

What breaks — and what to do about it#

Every Google Workspace to Zoho migration hits at least three items in this table. None are showstoppers, but each has to be handled before it becomes a support ticket.

Rollback plan#

Every step is reversible up to the point where you cancel Google Workspace or delete a user. Here is how you back out cleanly at each stage.

1. 1

   If the migration is corrupting folder structure on the pilot batch

   Stop the migration. Delete the imported folders on the pilot users in Zoho (this does not touch Gmail). Revise the profile — usually the fix is toggling the folder-mapping option or excluding a problematic label — and retry on the same pilot users before releasing the full run.

2. 2

   If DNS is cut over and mail is bouncing

   Revert MX to Google's values immediately. Senders retry for at least 24 hours, so anything caught inside that window is not lost. Check DMARC aggregate reports the next day to see what did not deliver. Diagnose in a staging domain, not the live one, before trying the cutover again.

3. 3

   If you decide against Zoho within the first month

   Turn off the Google Admin forwarder if you set one up. Revert MX to Google's values and remove the Zoho include from SPF. Cancel the Zoho subscription within its refund window. Your Google Workspace tenant is untouched — you only need to reconfigure any aliases or filters that were rebuilt on the Zoho side.

4. 4

   If mail went missing during the overlap

   Compare the source mailbox on Google (still live) against the destination on Zoho for the affected user. The migration keeps a per-message log. Restart the sync for that user only; Zoho de-duplicates on Message-ID and re-copies anything the first pass missed.

Doing it without downtime#

Zero-downtime is really about ordering. The order that keeps every user reachable throughout is: pre-create users → run IMAP migration with Google still live → verify → cut over DNS → keep Google forwarding on for two weeks. Each step overlaps the next so mail sent to your domain always reaches at least one live mailbox.

The step people get wrong is DNS. They cut MX before the migration has caught up, and messages that arrive in the gap between the last IMAP fetch and Zoho becoming the primary MX target end up split across two places. Wait until the migration reports complete for at least 24 hours, then flip DNS in a quiet window (early Saturday works well for most orgs), then let the Google forwarder mop up stragglers for two weeks.

Where AI Emaily fits after the move#

Zoho gives you the mailbox — the domain, the storage, the user management, the delivery infrastructure. None of that is what we do. We build AI Emaily, and it is a mail client with an AI agent on top, not a mail provider. On a Google Workspace to Zoho migration our role only starts after Zoho is in place and stable.

Once Zoho holds the mail, connect it to AI Emaily over IMAP and let the agent triage the inbox, draft replies in each user's Personal Context brain voice, and close routine loops with approve-before-send by default. The label-to-folder duplication and the missing filters the migration inherited are exactly the noise a triage layer flattens. Pricing is a 7-day free trial on Pro or Autopilot (card required), so a team can pilot it on a subset of users before rolling out.