How to Migrate from Microsoft 365 to Zoho Workplace: A Step-by-Step Guide

A Microsoft 365 to Zoho Workplace migration is a project most IT owners put off longer than they should, mostly because the switch touches every mailbox in the company on the same day. Done in the right order, though, it is a well defined piece of work: verify a domain, move mail and files, point DNS at the new system, then retire the old tenant. This guide walks through that sequence step by step, along with the mistakes teams most often report making along the way.

If you are still deciding whether to make the move at all, a side by side breakdown of the two platforms sits at Zoho One vs Microsoft 365 for small business. This piece assumes that decision is already made and focuses only on executing the migration itself.

Why teams move from Microsoft 365 to Zoho Workplace

Cost is usually the first driver that gets a migration on the agenda. Zoho Workplace bundles mail, document editing, WorkDrive storage, meetings and chat into a single per-user plan, and for teams comparing per-seat pricing against Microsoft’s business tiers, the gap is often enough to justify the switch on its own. The driver that matters more once the project is underway is consolidation. A company already running Zoho CRM, Zoho Books or Zoho People gains a single admin console, one identity system and one billing relationship once mail and documents sit on the same platform, which is a different proposition to buying email in isolation. That is worth reading against the wider suite comparison at Zoho One vs Microsoft 365 and Dynamics if your business also touches Dynamics-adjacent tools.

A smaller group of teams move for reasons closer to control: fewer admin layers, a support model that does not route through a large reseller channel, and a preference for one vendor relationship rather than several. None of this changes the mechanics of the migration itself. The steps are the same whether cost or consolidation got the project approved.

What to plan before you start

Most failed migrations share one root cause: someone started moving mail before anyone had a full picture of what needed to move. Four things are worth settling first.

Audit users and mailboxes

Build a full list of every account in the current tenant: primary mailboxes, shared mailboxes, distribution lists, mail-enabled security groups, aliases and any service accounts that send mail programmatically. Note mailbox sizes too, since large mailboxes take longer to move and are more likely to hit throttling limits.

Clean up before you move, not after

Old mail, abandoned folders and duplicate calendar entries do not get better by crossing platforms. Migrating a mess just gives you a smaller mess in a new place. A general framework for deciding what to bring across and what to leave behind sits in the Zoho data migration guide, and the same principle applies to mailboxes as it does to CRM or ERP records.

Decide on a coexistence window

Very few teams can cut every user over in one motion. A coexistence window, where mail is still reachable in the old tenant while the new one is being populated, gives you room to test the migration tool on a handful of accounts before committing everyone. For small teams this might be a day or two; past twenty or thirty users, plan for longer.

Back up independently of the migration tool

Export a full copy of mailboxes and files before you start, using a method separate from whatever tool you use to migrate. Migration tools are generally reliable, but a backup that exists outside the tool you are trusting is the only real insurance if something goes wrong midway.

The migration steps

Once planning is done, the actual move follows a fairly fixed order. Skipping ahead, particularly on the DNS steps, is where most of the pain in a rushed migration comes from.

1. Create the Zoho org and verify the domain

Sign up for Zoho Workplace and add your domain in the admin console. Zoho will ask you to add a TXT record to your domain’s DNS to prove ownership. This does not touch mail flow yet, so it is safe to do early and in parallel with the planning work above.

2. Set up users

Create user accounts, either individually or through a bulk CSV import, and assign the correct Workplace license to each. Matching usernames to the existing Microsoft 365 addresses saves confusion later, since mismatched addresses are a common source of missed mail during coexistence.

3. Migrate mail, calendars and contacts

Zoho Mail’s admin console includes an IMAP based migration tool built for this move. Point it at the source server (Microsoft 365 mailboxes are reached through outlook.office365.com), authenticate against the source account, and run the migration per mailbox or in bulk. Calendars and contacts generally move through the same process, though recurring calendar series are worth checking individually once it finishes.

4. Move files to WorkDrive

Files in OneDrive and SharePoint need to be exported and re-uploaded, or moved with a sync client if the data volume makes a straight download and upload impractical. Smaller libraries can usually be dragged into WorkDrive folders directly. Preserve the existing folder structure where you can, since flattening everything during the move creates cleanup work later rather than less of it.

5. Set SPF, DKIM and DMARC

Outbound mail from Zoho Mail needs its own authentication records, you cannot simply carry over the SPF and DKIM entries pointed at Microsoft’s servers. Add Zoho’s SPF include, generate and publish the DKIM key from the Zoho Mail admin console, and add a DMARC record once both are in place. Skipping this step is one of the fastest ways to have outbound mail from the new domain land in spam.

6. Cut over MX records

This is the step that actually redirects incoming mail. Lower the TTL on the existing MX records a day or two ahead of the change so the cutover propagates faster, then update the MX records to point at Zoho Mail once mail is confirmed flowing correctly to test accounts. Expect a window of a few hours where propagation is inconsistent across networks.

7. Decommission the old tenant

Do not cancel the Microsoft 365 subscription the moment MX records change. Keep it live and read-only for a settling period, typically a couple of weeks, in case anything needs re-checking against the original mailboxes. Once nothing is missing, export a final archive and close out the licenses.

Common pitfalls owners report on forums

A few problems come up often enough in forum threads about this exact migration that they are worth planning around rather than discovering mid-project.

• Shared mailboxes and distribution lists. These rarely carry over cleanly through an automated tool. Owners commonly report recreating shared mailboxes and mailing lists by hand in Zoho Mail and re-adding members one at a time.
• Calendar invites on recurring series. Individual meetings tend to migrate fine, but long-running recurring series sometimes break sync partway through, and attendees end up needing to re-accept invites that were already confirmed.
• Per-user credentials left behind. Users forget to update saved passwords in mobile mail clients and mail settings on personal devices, which shows up as a wave of “I can’t get my email” tickets right after cutover.
• MX propagation delay. Even with TTL lowered in advance, some networks cache DNS longer than expected, so a portion of inbound mail can be delayed by several hours during cutover.
• Missed automation rules. Outlook rules and Exchange transport rules do not migrate automatically. Anything that auto-forwards or auto-files mail needs to be rebuilt manually in Zoho Mail, and it is easy to forget a rule exists until the behaviour it created quietly stops.

A realistic timeline by team size

Timelines vary more with mailbox complexity than with raw headcount, but as a general guide:

• Under 20 users, no shared mailboxes or hybrid setup: mail and file migration is often achievable within a few days, including a short coexistence window.
• 20 to 100 users: plan for two to four weeks once you account for shared mailboxes, distribution lists, and a longer coexistence period to catch issues before full cutover.
• 100 or more users, or any hybrid Exchange setup: projects here stretch to several weeks or a couple of months. Hybrid environments, multiple domains, and heavy reliance on transport rules or compliance retention policies all add real time, and there is no shortcut around testing each one individually.

Larger and hybrid environments genuinely get fiddly. Anyone promising a same-week cutover for a 200-person hybrid Exchange tenant is underselling the manual recreation work involved, particularly around shared mailboxes and mail flow rules.

When to run it yourself vs bring in a partner

A small team with straightforward mailboxes, no shared mailboxes to speak of, and someone comfortable with DNS can generally run this migration in-house using Zoho’s built-in tools. The steps above are not complicated individually, and Zoho’s documentation covers each one.

Outside help makes more sense once the environment gets complex: a meaningful number of shared mailboxes and distribution lists, a hybrid Exchange setup, compliance or retention requirements that need replicating exactly, or simply no one internally with time to own the project while also keeping the business running. Aaxonix works through migrations of this kind as part of broader Zoho implementation projects, and can also advise on whether Zoho Workplace makes sense against alternatives like Google Workspace, covered separately at Zoho Workplace vs Google Workspace for small business.

None of the steps in this guide are individually difficult, and Zoho’s own tools cover most of the mechanics. What determines how smooth the project feels is how much planning happens before the first mailbox moves, and how honestly the team accounts for shared mailboxes and automation rules that do not migrate on their own.