Migrate Exchange to Zoho Mail: A Practical Engineer's Guide

Most Exchange-to-Zoho migrations stall in the same three places: EWS impersonation rights, folder hierarchy depth, and the way Zoho's wizard handles items larger than 30 MB. None of those are deal-breakers, but discovering them at 3am during cutover is. This guide walks through a real Exchange 2016 to Zoho Mail Suite migration the way a sysadmin actually runs one, with the numbers, the gotchas, and the order of operations that keeps you out of trouble.

Why teams move from Exchange to Zoho#

The motivation is rarely technical novelty. It is almost always cost, consolidation, or a CFO who has seen the renewal quote for Exchange CALs plus Windows Server plus the SAN holding the EDB files. Zoho Mail Suite at the standard tier costs a fraction of running on-prem Exchange when you factor in patching, backups, and the engineer-hours spent on quarterly cumulative updates.

The other common driver is consolidating onto Zoho's broader suite. If finance, sales, and support are already in Zoho CRM, Books, and Desk, moving mail off Exchange removes one of the last reasons to keep a Windows server farm in the rack.

What you give up is the deep Outlook integration, MAPI over HTTP, and any custom transport rules that depend on Exchange-specific cmdlets. Zoho has analogues for most of these, but they are not drop-in replacements. Budget time for a rules audit before you start moving mail.

If you are also evaluating whether Microsoft 365 would be a better landing zone, our Exchange to Office 365 migration walkthrough covers that direction in detail and is worth a side-by-side read before you commit.

Pre-migration audit#

Run this on the Exchange Management Shell before you touch Zoho:

Get-Mailbox -ResultSize Unlimited | Get-MailboxStatistics |
  Select DisplayName, ItemCount, TotalItemSize, LastLogonTime |
  Export-Csv mailbox-audit.csv -NoTypeInformation

You want this CSV in front of you for the entire project. Sort by TotalItemSize descending. The top 5 percent of mailboxes will account for 40 to 60 percent of your total migration time. Plan to migrate those first, in parallel with the bulk batch, so you are not waiting on a 78 GB executive mailbox to finish at the end of the project.

Also pull:

• Distribution groups: Get-DistributionGroup | Get-DistributionGroupMember — Zoho recreates groups, but you will manually re-add members.
• Shared mailboxes: Get-Mailbox -RecipientTypeDetails SharedMailbox — these need special handling, covered below.
• Resource mailboxes: rooms and equipment do not migrate cleanly; you recreate them in Zoho.
• Mailbox forwarding rules: server-side rules (Get-InboxRule) do not survive the migration. Document them.

Zoho-side preparation#

Provision your domain in Zoho Mail Suite first. You will need to:

1. Verify domain ownership via a TXT record or CNAME on the DNS host.
2. Create users in bulk by uploading a CSV — match Display Name, Email Address, and Password columns exactly.
3. Set the storage plan that covers your largest mailbox. Zoho's per-user storage caps are firm; a 50 GB mailbox will not fit into a 30 GB plan.
4. Generate a Zoho admin account specifically for the migration. Do not reuse a daily-driver login.

Do not switch the MX records yet. That happens at the end. For now, Zoho should be invisible to end users.

Configuring EWS for Zoho#

Zoho's migration wizard authenticates against Exchange Web Services. Confirm three things:

EWS endpoint reachability. From a machine outside your perimeter, hit https://mail.yourdomain.com/EWS/Exchange.asmx. You should get a 401 prompt for credentials. If it times out, your firewall is blocking Zoho's source IPs. The Zoho documentation lists the current IP block — whitelist it.

Service account with impersonation rights. Create a dedicated account, then grant it ApplicationImpersonation:

New-ManagementRoleAssignment -Name "ZohoMigrationImpersonation" `
  -Role ApplicationImpersonation -User zoho-migration@yourdomain.com

This lets one account read every mailbox without you handing over individual passwords. Without it, you will be entering 500 passwords by hand. Do not do that.

Throttling policy override. Default Exchange throttling will choke a multi-user migration. Create a throttling policy with relaxed limits and assign it to your migration account:

New-ThrottlingPolicy -Name ZohoMigration `
  -EwsMaxConcurrency Unlimited -EwsMaxSubscriptions Unlimited `
  -EwsCutoffBalance Unlimited -EwsRechargeRate Unlimited `
  -EwsMaxBurst Unlimited
Set-Mailbox zoho-migration@yourdomain.com -ThrottlingPolicy ZohoMigration

Running the migration#

In the Zoho admin console, navigate to Mail Administration → Migration → Add Migration, choose Exchange Server (EWS), and enter:

• Server URL: https://mail.yourdomain.com/EWS/Exchange.asmx
• Authentication: NTLM or Basic (NTLM if your Exchange is domain-joined; Basic if you have an edge proxy stripping NTLM)
• Admin username and password for the impersonation account

Then upload a CSV mapping source to destination addresses. The format is two columns: SourceAccount,DestinationAccount.

1. Run a 3-user pilot

   Pick three test users with varied mailbox profiles: one small (under 2 GB), one mid (5–10 GB), one large (over 20 GB). Start the migration and let it complete fully before adding more users.

2. Validate the pilot

   Log in as each pilot user. Check folder counts, total item count against the source, calendar (manually exported), and sent items. Flag any OAuth2 token expired or Message too large for destination errors in the migration log.

3. Roll out in batches of 20

   Zoho's wizard handles concurrent jobs, but parallel mailbox processing past 25 users tends to slow each individual mailbox. Twenty per batch is the sweet spot.

4. Monitor and resolve errors

   Watch the migration dashboard. Common errors include AUTHENTICATIONFAILED (re-grant impersonation), folder name conflicts, and items over Zoho's per-message size limit (default 30 MB, can be raised to 50 MB).

5. Run a delta sync

   Twenty-four hours before MX cutover, run a delta sync. Zoho's wizard remembers prior runs and only pulls items newer than the last successful pass.

Cutover day#

T-48 hours: drop MX TTL to 300 seconds on your DNS provider.

T-1 hour: stop accepting new mail on Exchange. Set Set-TransportConfig -InternalSMTPServers @{Add=...} to your old IP, then disable inbound transport.

T-0: change the MX record to Zoho. Verify resolution from multiple geographic locations using dig MX yourdomain.com @1.1.1.1.

T+15 minutes: send a test email from a Gmail account. It should land in Zoho. Send a reply from Zoho. It should be delivered back.

T+1 hour: run the final delta sync to pull any messages that arrived at Exchange during the MX propagation window.

Shared mailboxes and resource calendars#

Exchange shared mailboxes are not real users. Zoho shared mailboxes are. The cleanest path:

1. Recreate each shared mailbox as a regular Zoho user with a temporary password.
2. Run the migration against it as if it were a normal mailbox.
3. After migration, convert it to a Zoho shared inbox via Mail Administration → Shared Inboxes.
4. Assign delegate permissions to the same users who had access in Exchange.

Resource mailboxes (rooms, equipment) do not migrate. Recreate them in Zoho and rebuild any booking policies manually.

Outlook reconfiguration#

Zoho Mail does not speak MAPI. Your Outlook clients will reconfigure as IMAP or ActiveSync. Push new Outlook profiles via Group Policy or your MDM, pointing to:

• IMAP: imap.zoho.com:993 (SSL)
• SMTP: smtp.zoho.com:465 (SSL) or 587 (STARTTLS)
• ActiveSync: mobile.zoho.com

If users authenticate with two-factor, they need an app password for IMAP and SMTP — explain this clearly in your cutover comms or your help desk will spend two days fielding the same ticket.

For users who lived in Outlook for years, the Zoho Outlook plugin restores some calendar and contact sync. It is not a one-for-one replacement.

Where Mailbox Taxi fits#

Zoho's built-in wizard is competent for clean, full-mailbox transfers. It struggles in three scenarios where running a desktop IMAP-to-IMAP tool alongside it is faster and safer: filtered migrations (only certain folders or date ranges), individual users with very large attachments, and re-runs after a failed sync.

Mailbox Taxi runs on your local machine, talks IMAP to both Exchange and Zoho, and gives you per-folder control. You can do a full first-pass with Zoho's wizard, then use a desktop tool for the messy outliers without uploading credentials to a third party.

Common errors and fixes#

AUTHENTICATIONFAILED — almost always the impersonation rights have not propagated. Wait ten minutes and retry. If it persists, run Get-ManagementRoleAssignment -RoleAssignee zoho-migration@yourdomain.com and confirm the role is listed.

Too many simultaneous connections — Zoho is rate-limiting. Reduce your batch size from 20 to 10 and retry.

Folder UTF-7 conversion error — non-ASCII characters in folder names. Pre-process folders in Exchange:

Get-Mailbox -ResultSize Unlimited | ForEach-Object {
  Get-MailboxFolderStatistics $_ | Where-Object {$_.Name -match "[^\x00-\x7F]"}
}

Rename offending folders to ASCII-only.

Message too large for destination — Zoho's per-message ceiling. Raise it in the admin console under Mail Settings → Send/Receive limits, or manually move large messages out of the migration scope.

STARTTLS handshake failed — happens when Zoho's IPs are blocked by your edge appliance. Whitelist the published range.

For broader IMAP-side error patterns that apply to any migration, the complete email migration guide has a longer error appendix.

Post-cutover validation#

Three checks within the first week:

1. Item count delta: pull a Zoho mailbox report and compare to the source Get-MailboxStatistics data. Variance under 0.5 percent is normal — Exchange counts hidden items that IMAP-style migrations do not see.
2. DNS hygiene: confirm SPF includes zoho.com, DKIM is published, and DMARC is at least p=none with a reporting address.
3. Calendar smoke test: send a meeting invite from a Zoho user to an external Gmail user. It should appear correctly with the right time zone.

After 30 days of stable operation, you can decommission the Exchange transport role. Keep the mailbox role for another 60 days as an archive — disk is cheaper than the panic of realising you needed something a user "definitely deleted" three months ago.

If your end state is actually Microsoft 365 instead of Zoho, our Zoho to Office 365 walkthrough shows the reverse direction and is the right reference if you change your mind partway. And for teams whose final destination is Google's stack, the Exchange to Google Workspace guide follows the same overall structure with Workspace-specific quirks. The pillar Exchange migration guide ties together every Exchange-source migration we cover.