Migrate Zoho Mail to Office 365: An IMAP Cutover Playbook

Zoho Workplace and Microsoft 365 serve a similar audience and the move from one to the other usually comes down to organisational fit rather than feature gaps. Teams move to Microsoft 365 because the rest of the business is on Teams, because the procurement team has an existing volume agreement, or because compliance requirements push them into a tenant that already holds the rest of the company's data. The technical migration is straightforward in shape but unforgiving in detail. Zoho exposes a clean IMAP endpoint per region. Exchange Online accepts IMAP inbound, although many tenants now require OAuth and disable basic auth at the org level. The hard parts are licence sequencing, IMAP enablement at both ends, and the DNS cutover that has to happen at exactly the right moment so that no in-flight mail lands in a half-empty mailbox. This guide covers the full sequence for a domain-level cutover, with notes on how to scale the same play across an entire small business in one weekend.

What you need before the maintenance window#

A Zoho-to-Office 365 cutover is one of those jobs where the prep takes as long as the migration. The IMAP transfer itself is mechanical; the planning around it is where mistakes happen. Before you start:

• Confirm every user who will be moved has an Exchange Online Plan 1 or higher licence attached, and that the licence is active (sign in to Outlook on the web for each to verify the mailbox actually exists).
• Confirm IMAP is enabled on the destination tenant under Microsoft 365 admin centre > Settings > Org settings > Modern Authentication, and per-mailbox under each user's mail settings.
• Confirm the source Zoho cluster (global, EU, India, Australia, Saudi Arabia) and capture the correct IMAP hostname for that region.
• Generate Zoho app-specific passwords for any account with 2FA on. Treat these as credentials.
• Lower the TTL on the existing MX records to 300 seconds at least 24 hours before the cutover.
• Decide whether you are doing a cutover migration (one weekend, big bang) or a staged migration (users moved in batches over a fortnight). For mailboxes under about 50, cutover is simpler.

If your destination tenant has Conditional Access policies enforcing modern authentication only, your admin needs to allow the migration source IP or use a tool that supports OAuth on the destination side. Many tenants now block basic-auth IMAP entirely; this is the most common cause of Basic authentication is disabled errors on day one.

Endpoints#

• Zoho IMAP host: imap.zoho.com (global), imap.zoho.eu (EU), imap.zoho.in (India), imap.zoho.com.au (Australia)
• Zoho IMAP port: 993 with SSL/TLS
• Zoho credential: full address plus app-specific password (or account password if 2FA off)
• Office 365 IMAP host: outlook.office365.com
• Office 365 IMAP port: 993 with SSL/TLS
• Office 365 credential: user principal name plus password or OAuth token

For batched migrations, Microsoft's IMAP migration service in the Exchange admin centre wants a CSV with one row per user containing email, username, and password. The CSV approach works well for 10 to 1,000 users; below 10, a desktop tool is faster to set up.

Steps#

1. Audit the Zoho mailbox and tenant

   For each user being moved, sign in to Zoho Mail (or have them do it) and capture folder structure and approximate size. The Zoho admin Control Panel under User Details shows mailbox size per user, which is faster than asking people one by one.

   On the Microsoft side, open the Microsoft 365 admin centre and confirm every target user has an Exchange Online licence applied and a mailbox provisioned. The licence-to-mailbox lag can be up to 30 minutes; verify by signing in to Outlook on the web.

   Document any shared mailboxes or group mailboxes that exist in Zoho. These need different treatment because Exchange Online represents them differently. Shared mailboxes in Office 365 do not require their own licence but they do require explicit creation in the admin centre.

2. Enable IMAP and generate Zoho app password

   In Zoho Mail Control Panel, go to Mail Accounts > IMAP/POP and confirm IMAP is enabled organisation-wide. If individual users have disabled it for themselves, re-enable it in their Mail Settings.

   If two-factor authentication is on for any account, the user needs an app-specific password. Go to accounts.zoho.com (or the regional equivalent), open Security > App Passwords, and create one. Copy it immediately. Zoho displays each app password only once.

   Right region, right credential

   Generate app passwords from the regional accounts page that matches the user's cluster. A password issued at accounts.zoho.com will not work for an account that lives in the EU cluster. Mismatched regions produce AUTHENTICATIONFAILED errors that look identical to a wrong password.

3. Prepare the Office 365 mailbox

   Confirm each target user can sign in to Outlook on the web. Confirm IMAP access is enabled per mailbox under the user's mail settings. If you are running the migration from the Exchange admin centre's IMAP migration service, create the migration endpoint pointing at the Zoho IMAP hostname for the relevant region and test the connection with a single account first.

   For domain cutover, add the Zoho domain to the Office 365 tenant and complete the domain verification, but do not change the MX records yet. The domain has to be verified in Microsoft 365 before you can assign mailboxes that use the domain in their primary address, but switching the MX is a separate later step.

4. Run a small dry run

   Pick one user, ideally yourself or another admin, and run a test migration on a single folder. Verify in Outlook on the web that:

   • The folder appears in the Office 365 tree.
   • Original dates are preserved.
   • Read and unread states are preserved.
   • Attachments open correctly.
   • Non-ASCII characters render correctly.
   • Subfolder hierarchy is intact.

   If anything looks wrong, fix it now. The dry run catches most issues, including the most embarrassing one, which is a tool that defaults the destination timezone to UTC and reorders all dates by 5 to 8 hours.

5. Run the full migration

   Start the bulk migration at the beginning of your maintenance window. For a desktop tool, that means setting it running with the full mailbox list. For the Exchange admin centre's IMAP service, that means creating the migration batch and starting it.

   Monitor logs for throttling. Zoho is generally relaxed about IMAP load but spikes when many users in the same domain hit the server at once can trigger short-lived rejections. Exchange Online has APPEND throttles that vary by tenant. If the migration tool is paying attention to server responses, it will back off automatically.

   Expect a 20 GB mailbox to run for 4 to 8 hours. Many smaller mailboxes in parallel typically finish faster per-mailbox because Zoho handles the spread better than concentrated load on a single account.

6. Cut over MX records and verify

   Once the IMAP run reports completion, do a delta sync if your tool supports one — a quick second pass that picks up any new mail that arrived during the long run. Then change the MX records to point at <tenant>.mail.protection.outlook.com. New mail begins arriving in Office 365.

   For the next 24 hours, leave Zoho live as a fallback. Some sending mail servers cache DNS responses past the TTL, so a small percentage of new mail will continue to land at Zoho. Set Zoho to forward to the new Office 365 address as a belt-and-braces measure.

   Run final verification searches in Outlook on the web for each user. Check folder counts, find a known-difficult old attachment, confirm flagged messages are present.

Gotchas worth knowing#

Zoho's IMAP server returns \Recent flags on messages that have been fetched recently. Some destination IMAP servers, including Exchange Online, treat \Recent as a hint about new arrivals. The result is that Outlook on the web may briefly show migrated messages as "new" for the first few hours after the migration. The flags settle within a day.

Exchange Online enforces a Recoverable Items quota that is separate from the visible mailbox quota. If users delete folders aggressively after the migration to tidy up, the deleted items still count toward storage for 14 days. On a freshly populated mailbox this can briefly tip the user over their quota and trigger 552 5.2.2 Mailbox full rejections. Wait two weeks before mass-deleting, or have the admin purge Recoverable Items.

The Microsoft IMAP migration service has a per-batch concurrency limit and a per-user concurrency limit that are not always documented. In practice, a batch of more than about 50 users tends to run sub-optimally because Microsoft's service serialises some operations internally. For large orgs, run several smaller batches in parallel rather than one big batch.

Errors you are likely to see#

• AUTHENTICATIONFAILED on Zoho — wrong password, wrong region, or 2FA without an app password.
• LOGIN failed: Basic authentication is disabled on Office 365 — tenant has disabled basic auth IMAP. Use OAuth or temporarily enable IMAP for the migration mailbox.
• Too many simultaneous connections — usually on Zoho when too many parallel streams hit one mailbox.
• OAuth2 token expired — refresh logic in the tool failing. Restart with a fresh token.
• 552 5.2.2 Mailbox full — Exchange Online quota tripped, often by Recoverable Items pressure.

DNS cutover and the communication plan#

The DNS cutover sequence makes the difference between a clean migration and a confused one. Lower the TTL on the MX records 24 hours before the cutover, run the IMAP migration, do a quick delta sync, then change MX. Forward Zoho to Office 365 for at least 30 days afterwards. Send a one-paragraph note to the team a week before the cutover with the maintenance window, and a second note on the morning of the change confirming what to do if mail looks odd.

The same DNS-and-forward pattern applies to a Zoho to Outlook.com move or a Zoho to Gmail migration, with the destination-side details changing. The broader Office 365 migration guide goes deeper on tenant prep and Conditional Access. The generic IMAP to Office 365 walkthrough is useful when the source is a custom IMAP host rather than Zoho. The complete email migration guide covers the framework across any provider pair.

Recovery and rollback#

If the IMAP migration fails partway, the tool's resume logic should pick up where it left off. The risk on resume is duplicate messages, not missing ones. Modern tools deduplicate by Message-ID hash. If you end up with a few hundred duplicates anyway, Outlook on the web's bulk-delete handles them.

If the entire cutover goes wrong — for instance, the destination tenant has an unexpected mailbox quota lower than you planned for — you can roll back by changing MX back to Zoho. Mail in flight during the rollback window may be delivered to either side and you will need to copy stragglers across by hand afterwards. Plan the rollback before you need it.