The migration nobody budgets a morning for
Say a 14-person freight broker has run on Zoho Mail since the day somebody bought the domain. It worked fine. Then the company standardizes on Google Workspace for documents and meetings, and mail is the last thing still living somewhere else. Everybody assumes the move is an afternoon: point the MX records at Google and go home.
The MX record is not what costs you the week. It is the years of mail sitting in those mailboxes, and the fact that Zoho hands none of it over until somebody turns IMAP on account by account and works out which users cannot sign in with their normal password. We run this route often enough to know where it stalls, and it almost always stalls on the Zoho side, before Google is involved at all.
Turning IMAP on in Zoho, per user and per policy
Google's import reads the old mailbox over IMAP. If IMAP is off, the import fails at the connection test and tells you very little about why. Three separate things decide whether a given Zoho mailbox will answer:
- The per-user setting. IMAP access is a user preference in Zoho Mail, under Settings and then Mail Accounts, in the IMAP Access section. Switching it on for yourself does nothing for the other thirteen people.
- The organization policy. An administrator can block IMAP for the organization, and when that is the case the user-level checkbox will not save you. Check the policy before you start chasing individual accounts.
- The plan. Zoho's own IMAP help page is where to confirm this for your account: IMAP access is not offered to newly registered free-plan users, and the free plan is only available in some data centers. If the domain is on a paid Zoho plan this is not your problem. If somebody set it up free years ago, check it before you promise anyone a date.
Then there is the password. A Zoho account with two-factor authentication turned on, and any organization user who signs in through SAML, cannot authenticate an IMAP client with the normal web password. Those users need an application specific password, generated in the Zoho account under Security and then Application Specific Passwords. Zoho displays that password once and never shows it again, so whoever generates it has to paste it straight into the migration sheet. The passwords do not expire, which is convenient during a migration and worth revoking the week after.
The server name depends on what kind of Zoho address it is. Google's documentation names both: imappro.zoho.com for a mailbox on your own company domain, and imap.zoho.com for a personal address at zoho.com. IMAP over TLS runs on port 993.
The import from the Google Admin console
Once IMAP answers, the Google half is the easy half. The conditions Google asks for, checked on 26 October 2026: a super administrator has to set up and run the migration, and a reseller cannot run it on a customer's behalf; the source server has to be reachable from Google's IP ranges; IMAP has to be on for the Zoho accounts and for the Workspace accounts; and the Workspace users have to exist already. The import writes into accounts, it does not create them.
In the Admin console the path is Data, then Data import and export, then Data Migration. Pick IMAP as the source, enter imappro.zoho.com as the server, and run the connection test before anything else. A failed test at this point is a Zoho problem rather than a Google one, so go back through the three checks above instead of retrying.
How you hand over the users depends on how many there are. Up to twenty, you enter each one in the console. Above twenty, you upload a CSV carrying the IMAP address, the IMAP password and the destination Workspace address on every row. The file has to be smaller than 128 MB, and one import covers up to 100 IMAP users, so a larger company runs several imports rather than one. One rule catches people while they are building the sheet: a single IMAP user cannot be split across several Workspace users. Map one to one, or many to one, never one to many.
Two things stay behind even when the import reports success. An attachment is skipped when the message plus the attachment goes over 25 MB, and when the file type is one Gmail blocks, executables being the usual case. On a mailbox full of scanned delivery notes that is a handful of messages rather than a disaster, but it is the kind of thing to say out loud before the migration, not after.
What the import brings, and what you move yourself
This is the table to settle before the first batch runs, because it decides how much of the work lands on somebody other than you.
| What | How it moves | What to plan for |
|---|---|---|
| Mail and folders | Google data import over IMAP | Folders arrive as labels; run a final pass right before the MX change |
| Calendars | Export from Zoho Calendar as ICS, import per user | Only calendars the user owns export, not subscribed or shared ones |
| Contacts | Export and re-import per user | Personal address books only; shared company contacts get rebuilt as directory entries or groups |
| WorkDrive files | Not part of the mail import at all | Plan it as a separate file migration with its own cutover |
| Groups and aliases | Recreated by hand in the Workspace Admin console | Build them before the MX change so nothing bounces on the day |
| Filters and signatures | Not migrated | Ask each person to capture theirs in the week before |
The row that surprises people is the last one. Filters and signatures are small, personal and invisible until the day they are gone, and they are the thing that makes a technically clean migration feel broken to the people living in the mailbox.
Calendars, contacts and WorkDrive
Zoho Calendar exports to ICS from Settings, then Calendar, then Calendars and My Calendars, using the export icon on the calendar you want. The limit worth knowing before you promise anything: only calendars the user owns come out that way. A calendar they merely subscribe to, or one that somebody else shared with them, does not export from their account, so it has to come from whoever owns it. On a team with one shared operations calendar, that is one more person to coordinate with and five minutes of work. On a team where everybody shares everything, it is an afternoon.
Contacts travel the same way, per user, as an exported file re-imported on the Google side. Company-wide address books are a different animal: in Workspace they are the directory, plus groups, so they get rebuilt rather than carried across.
WorkDrive is not part of a mail migration and should not be treated as an add-on to one. Files have their own permission model, their own shared folders and their own moment of cutover, and the two projects interfere with each other if you try to do them in the same week with the same people. We size it separately, and the file migration page covers how that side runs.
The MX switch and the Zoho records you retire
Mail only arrives at Google once the MX records point there. Google's instruction is to clear out the other MX records and publish a single one, host left blank or set to @, priority 1, value smtp.google.com. Registrars differ in how they want it typed: some need a trailing dot, some want the priority and the destination in one field. Google says the new records can take up to 72 hours to be recognized.
Type: MX Host: @ Value: smtp.google.com Priority: 1
What you are replacing are the Zoho records, mx.zoho.com, mx2.zoho.com and mx3.zoho.com. Leaving one of those behind at a higher priority number is a quiet failure: most mail reaches Google, and the fraction that retries lands in a Zoho mailbox nobody opens any more. Delete them in the same edit, then check the zone from outside rather than trusting the registrar's screen.
Authentication is the part that gets forgotten, and it is the part that sends your invoices to spam. While Zoho still sends for the domain, the Zoho include stays in SPF and the Zoho DKIM selector stays published. Once Zoho is done, both come out, and the Google values go in: the SPF include for Google and the DKIM key generated on the Authenticate email page in the Admin console, published under the selector that page gives you. Our Zoho Mail SPF, DKIM and DMARC guide has the Zoho side of those records in detail. Keep one SPF record, not two, and keep the DMARC record in place throughout so the reports tell you what is still sending as you.
Check the domain the day the MX changes rather than waiting for a customer to mention it. A message that fails authentication the week after a migration does not look like a migration to the person receiving it. It looks like you.
How Guanacos Tech helps
We run this route end to end for small and mid-sized teams: the IMAP audit on the Zoho side, the application specific passwords, the user mapping sheet, the import batches and the final pass, the calendar and contact exports, the groups and aliases rebuilt before the day, and the MX, SPF and DKIM change on cutover. In English and Spanish, across North America and Latin America, with Google-certified engineers who have been doing this since 2018. The scope is on the Google Workspace migration consulting page, and the hosting and IMAP routes in particular on the hosting email to Google Workspace page. A 30-minute call is enough to turn this into dates for your own domain and to name the items somebody on your side will have to rebuild by hand.
Sources
- Google Workspace Admin Help: Migrate email from an IMAP account
- Google Workspace Admin Help: About importing email with the data import tool
- Google Workspace Admin Help: Set up MX records for Google Workspace
- Zoho Mail Help: Access via IMAP
- Zoho Accounts Help: Application Specific Passwords
- Zoho Calendar Help: Import or Export Calendars
- Zoho Mail Admin Console Help: Configure email delivery (MX records)