Google Workspace to Zoho Mail Migration: The Cutover Plan for 2027

What should you list before the migration starts?

Start with a full inventory, because most cutover problems come from things nobody wrote down. Export the user list from the Google admin console and note every alias, group, shared mailbox, forwarding rule and third-party app that sends mail as your domain, such as your CRM, billing system or website forms.

Record your current DNS too: MX, SPF, DKIM, DMARC and any verification records. Note who controls the DNS host and make sure they are available on cutover day.

Check mailbox sizes as well. Large mailboxes take longer to migrate and may need more storage than the Zoho plan you picked. Zoho's migration settings let you pause when storage reaches a set threshold and filter by folder or date range, so you can decide whether to bring over every year of mail or only recent years. Agree that decision with each team before you start, because it is hard to change once users are working in Zoho.

When should DNS changes happen?

DNS timing is the part of the plan that most affects users. Domain verification in Zoho can be done days ahead, because it uses a TXT or CNAME record that does not change where mail goes. The MX change is the real cutover and should happen last.

A few days before cutover, lower the TTL on your MX records so the change spreads faster. Pick a quiet time for the switch, such as a Friday evening or weekend in your main time zone. Update SPF to include Zoho and add the Zoho DKIM key at the same time. Our answer on setting SPF, DKIM and DMARC for Zoho Mail gives the exact records to check.

How do mailboxes, contacts and calendars move?

Zoho's admin console has a Google Workspace migration option that moves mail, contacts and calendars. Zoho's help page says you need a Google super admin email, a service account and a key file, and that users must already exist in Zoho Mail before calendars are migrated. The domain in Zoho must match the Google domain.

Run the first full migration a week or so before the MX change. That moves the bulk of older mail while staff keep working in Gmail. After the MX change, run a sync to pick up anything that arrived in between. Zoho says its Sync option is being rolled out in phases and may need to be enabled by Zoho support, so confirm it is active on your account early. You can also rerun a migration for the same users to pick up new mail.

Two details catch people out. Gmail labels become folders in Zoho, so a message with three labels is copied into three folders and uses storage three times. Zoho suggests excluding some label folders, such as Important, to reduce duplication. Also, users should not change their Google passwords until migration is complete. Google Drive files are a separate move to WorkDrive. For the step-by-step mail screens, see our answer on migrating email from Google Workspace to Zoho Mail.

What happens to aliases, groups and sending apps?

Aliases and groups need to be rebuilt in Zoho before the MX change, or mail sent to them will bounce. Add every alias to the right user, create each group with the same address and members, and set who can post, including whether outside senders are allowed. Test each group by sending from an outside account.

Every app that sends as your domain needs attention. If an app relays through Google's SMTP servers, switch it to Zoho's SMTP settings or to the app's own sending service with the right SPF and DKIM records. Missing this step is a common reason mail lands in spam after a move. Check the sending settings of each app before cutover day, not after, and send a test message from each one once the new records are live.

How should you tell users, and what is the rollback plan?

Tell users three times: a week before, the day before and on the morning after the switch. Each message should say what changes, what they need to do and who to contact. Give them the web address, mobile app links and a one-page guide to signing in with multi-factor authentication.

A rollback plan means you can point mail back to Google if something serious goes wrong. Keep Google Workspace licenses active for at least a short overlap after cutover, keep a copy of the old DNS values, and agree in advance who decides to roll back and on what grounds. Once you are confident mail flows correctly, cancel Google and remove its old records.

1. 1Week before: send the plan, the date and the sign-in guide.
2. 2Day before: remind users to finish drafts and not change passwords.
3. 3Cutover: change MX, SPF and DKIM, then send test mail in both directions.
4. 4Morning after: confirm sign-in works and point users to the help contact.
5. 5Rollback trigger: agree the issues that would justify reverting MX to Google.

What should you check in the first week?

Check mail flow every day for the first week. Send to and from Gmail, Outlook and a few customer domains, and check message headers to confirm SPF, DKIM and DMARC pass. Review the migration report for failed users or folders and retry them.

Also confirm calendars, shared calendars and meeting invites work, that mobile devices are set up, and that groups deliver to every member. Ask each team lead for a short list of issues at the end of day two and day five. If you would rather hand the whole move to a team, our Zoho Mail implementation service runs the cutover to a written, fixed-price plan, with 30 days of free fixes after go-live.

Frequently asked questions