Migrate Zoho Mail to Google Workspace: IMAP Cutover Guide

Zoho Workplace and Google Workspace cover similar ground for small and mid-sized businesses, and the move from one to the other is usually driven by people, not features. Teams move because the rest of the company is on Google Docs, because a parent organisation has standardised on Workspace, or because the IT lead wants to consolidate on the same vendor that owns Android and Chrome. Whatever the reason, the technical migration follows a well-trodden path. Zoho exposes a clean IMAP endpoint per region; Google Workspace accepts inbound mail via its Data Migration Service or via desktop IMAP tools. The interesting parts of the job are operational: licence sequencing, the DNS cutover, OAuth versus app-password authentication, and the handling of shared mailboxes and group aliases that Zoho structures differently from Google. This guide covers a domain-level cutover for a team of 10 to 100 users, with notes on how the same shape scales up or down. It assumes the technical owner is doing the work and has admin access on both sides.

What needs to be in place#

A team migration from Zoho to Google Workspace touches more moving parts than a single mailbox move. Before you set anything running:

• Every user in scope has a Google Workspace licence attached and a mailbox provisioned. Confirm each user can sign in to mail.google.com before the migration starts, even if the inbox is empty.
• The domain that currently routes to Zoho is added to Google Workspace and verified. This requires a temporary TXT record on the domain. It does not change mail flow — verification is separate from the MX cutover.
• IMAP is enabled at the Workspace level (Admin console > Apps > Google Workspace > Gmail > End User Access) and at the user level (each user's Gmail settings, though this is usually default-on for Workspace accounts).
• Zoho IMAP is enabled organisation-wide and per-user. Zoho's Control Panel under Mail Accounts > IMAP/POP shows the state.
• Each Zoho user has either two-factor verification off or an app-specific password generated for the migration.
• The IT lead has decided whether to use Google's Data Migration Service (DMS) or a desktop IMAP tool. DMS is easier for batches of 10 to 100 users; a desktop tool is faster for one or two users and gives more visibility into errors.

If your destination domain is already attached to a different Workspace account or to an old Microsoft tenant from previous experiments, untangle that before starting. Domain conflicts produce confusing errors much later in the process.

Endpoints#

• Zoho IMAP host: imap.zoho.com (global), or imap.zoho.eu, imap.zoho.in, imap.zoho.com.au for regional clusters.
• Zoho IMAP port: 993 with SSL/TLS
• Zoho credential: user address plus app-specific password if 2FA on
• Google Workspace IMAP host: imap.gmail.com
• Google Workspace IMAP port: 993 with SSL/TLS
• Google Workspace credential: OAuth (preferred) or user password plus Google app password

For the Data Migration Service, no per-user host configuration is needed on the destination side — DMS handles the destination internally. You supply the Zoho IMAP host, port, and per-user credentials, and DMS pulls from Zoho into each matching Google account.

Steps#

1. Audit Zoho mailboxes and tenant

   In the Zoho Mail Control Panel, open Mailbox Storage to see size per user. Export the list as CSV if you have many users. Note any shared mailboxes — Zoho calls these "Group Mailboxes" or "Shared Folders" depending on the configuration. These need different handling because Google Workspace represents shared mailboxes as Google Groups, which is a different concept.

   For each user, decide whether the entire mailbox migrates or whether you skip Spam, Trash, or a Backups folder that has not been touched in years. Skipping these can cut hours off the run for almost no information loss.

   Capture the Zoho regional cluster. Look at the URL each user signs in at — mail.zoho.com is the global cluster, mail.zoho.eu is European, and so on. The migration tool needs the matching IMAP hostname.

2. Enable IMAP and generate Zoho app passwords

   In Zoho Mail Control Panel, confirm IMAP access is enabled organisation-wide under Mail Accounts > IMAP/POP Access. Re-enable per-user if individual users have disabled it.

   For users with two-factor verification on, generate app-specific passwords at the regional Zoho Accounts URL (accounts.zoho.com, accounts.zoho.eu, and so on). Label each one with the user's address. Copy each immediately — Zoho only shows app passwords once. Store them in a password manager that the migration tool can read or that you can paste from.

   App passwords are credentials

   An app password lets anyone with it sign in to that user's Zoho mailbox over IMAP without triggering two-factor verification. Treat them with the same care as account passwords. Plan to revoke each one within a day or two of the migration completing.

3. Prepare Google Workspace

   Add the migration domain in the Google Workspace admin console under Account > Domains. Verify ownership with the TXT record Google provides. Verification does not change mail flow; it just tells Google the domain is yours.

   Assign Workspace licences to every user in scope. Confirm each user can sign in to Gmail. Decide on a label prefix for migrated folders — Zoho/ is common and groups everything under one top-level label.

   If you are using the Data Migration Service, open it from the admin console (Account > Data Migration), pick Email, choose IMAP, fill in the Zoho IMAP hostname for the relevant region, and supply credentials per user via the CSV upload. If you are using a desktop tool, install it on a workstation with reliable connectivity and configure both sides.

4. Run a single-user dry run

   Pick one user — yourself or another admin is ideal — and migrate the full mailbox end to end. Do not just migrate one folder; you want to validate the full pipeline including the largest folders.

   Verify in Gmail:

   • Folder structure becomes labels under the prefix you chose.
   • Original dates are preserved on every message (sort the All Mail label by date and spot-check).
   • Read and unread states match.
   • Attachments open. Test PDFs, images, and an Office document if you have one.
   • Non-ASCII characters in subjects render correctly.
   • Subfolders nest correctly under their parent labels.
   • Shared mailbox content, if applicable, lands in the right Google Group or shared account.

   Fix anything broken before scaling out. The dry run is the cheapest way to catch a misconfigured tool or a forgotten setting. The Google Workspace migration guide goes deeper on Workspace-specific destination behaviour.

5. Run the full migration

   Start the bulk migration at the start of your maintenance window, typically Friday evening for a Monday cutover. For Data Migration Service, that means starting the migration batch from the admin console. For a desktop tool, it means setting the tool running with the full user list.

   Monitor for throttling. Zoho handles a domain-wide migration well but spikes can produce short-lived Too many simultaneous connections errors. Google's IMAP and DMS both throttle on the destination side. A well-written tool backs off automatically. If you see repeated OAuth2 token expired errors, refresh tokens on the destination side.

   For a 50-user organisation with average 5 GB mailboxes, plan 12 to 24 hours of runtime. Smaller orgs finish faster; larger ones benefit from running two or three parallel migration tools rather than one big one.

6. Cut over MX and verify

   Once the bulk run reports completion, run a delta sync that catches any new mail that arrived during the long run. Then change the MX records to point at Google's mail servers (ASPMX.L.GOOGLE.COM and the alternates). New mail begins arriving in Google Workspace.

   For at least 48 hours, leave Zoho live with forwarding enabled to the new Workspace addresses. Some sending mail servers cache DNS responses well past the TTL. Forwarding catches the stragglers.

   Run final verification per user. Search Gmail for an old PDF, a thread with accented subjects, a known flagged message. Check folder counts against Zoho. Numbers will be within a few percent on a clean run.

Gotchas particular to this pair#

Gmail conversation threading reorders the apparent order of messages in the All Mail view. Even with INTERNALDATE preserved, Gmail groups messages by Message-ID and References headers, and the thread's timestamp is the latest message in the thread. Users who are used to Zoho's strict per-folder timeline find this disorienting at first. Warn them.

Zoho's Group Mailboxes and Shared Folders do not map cleanly onto a single Google Workspace primitive. The closest equivalents are Google Groups with collaborative inbox enabled, or shared mailboxes implemented as a generic Workspace user with delegated access. Decide upfront which pattern you want and plan the migration accordingly. The IMAP migration only handles user-level mailbox content; the shared-mailbox structure has to be created in Workspace before or after the migration.

Zoho tags do not transfer over IMAP because tags are Zoho-specific metadata. If users rely on tags heavily, plan to recreate the most important tag taxonomies as Gmail labels in the days after the migration. Bulk relabeling in Gmail is fast.

The Data Migration Service writes migrated mail to Gmail labels rather than to native Gmail folders, which is correct behaviour but sometimes confuses users who expect to see a folder tree. The label sidebar in Gmail is the equivalent of the folder list in Zoho.

Errors you will probably see#

• AUTHENTICATIONFAILED on Zoho — wrong password, wrong region, or 2FA without an app password.
• Too many simultaneous connections — Zoho throttling under domain-wide load. Reduce parallelism.
• OAuth2 token expired — destination refresh failing. Re-authenticate.
• Lookup failed - server is busy — Gmail's transient throttle. The tool should retry.
• Quota exceeded on inbound APPEND — Gmail's per-day per-user limit hit. Pause for an hour and resume.

DNS cutover and communication#

The DNS sequence makes or breaks a team migration. Lower TTL on the existing MX records 24 hours before the cutover. Run the IMAP migration with MX still pointing at Zoho. Do a delta sync at the end. Change MX to Google. Forward Zoho to Google for at least 30 days.

A week before the cutover, send a one-paragraph note to the team explaining the maintenance window and what to expect. The morning of the cutover, send a second short note confirming the change is in progress. After the cutover, send a third note with the new Gmail URL and any setup steps users need to do (mobile reconfiguration, calendar reimport, contacts import).

For mixed strategies where some users want a personal Gmail account instead, the Zoho to Gmail walkthrough covers the same source side. For Microsoft destinations, the Zoho to Office 365 guide is the right reference. The generic IMAP to Gmail playbook is useful when the source is a non-Zoho IMAP host. The complete email migration guide covers the cross-cutting checklist that applies to any provider pair.

Recovery and rollback#

If a single user's migration fails mid-run, the tool's resume logic should pick up from the last completed folder. The risk on resume is duplicates, not data loss. Modern tools deduplicate by Message-ID hash.

If the Data Migration Service stalls — most common reason is a user whose Workspace licence has not actually attached yet — the admin console shows the per-user status. Fix the licence and resume that user.

If the entire cutover needs to roll back (rare, but possible if a critical app cannot find its mail), change MX back to Zoho. Mail in flight during the rollback window may be delivered to either side. Plan the rollback before you need it; do not improvise.