Moving Business Email in Kerala: What Migrating Between Google Workspace, Microsoft 365 and Zoho Actually Involves

ByBNW TEAM

Which data moves, which doesn’t, and the order of operations that keeps mail flowing on switch-over day

A business email migration looks like a software task. Mostly, it isn’t.

The migration tools from Google, Microsoft and Zoho are mature, and each vendor publishes detailed documentation for moving data onto its platform. What goes wrong is usually planning: the wrong migration method chosen, steps done in the wrong order, or something that was never going to migrate automatically being discovered after the old system has been switched off.

This guide covers what actually moves between the three platforms, how each vendor’s tools work, a time-sensitive change affecting anyone leaving Microsoft 365, and the sequence that keeps email flowing on the day you switch.

The One Distinction That Decides Most of the Outcome

Every migration method falls into one of two groups, and knowing which one you’re using matters more than anything else.

Protocol-based migration (IMAP or POP) reads mail from the old server the way an email app would. It works with almost any provider. But it moves email only. Microsoft’s documentation for IMAP migration into Microsoft 365 states that contacts, calendar items and tasks are not migrated. Zoho’s documentation says the same of its IMAP and POP tools — calendars and contacts have to be moved separately.

Native or app-based migration connects to the source platform through its own interfaces, with administrator authorisation, and can bring across calendars and contacts as well as email. Each vendor offers this only for specific sources.

So the first question isn’t “which platform?” but “which method does our source-and-destination combination support?” A business that relies heavily on shared calendars and moves via IMAP will arrive with its email intact and its calendars empty.

Moving toMoving fromNative tool (mail, calendar & contacts)IMAP (mail only)Google WorkspaceMicrosoft 365Yes — Admin console data importYesGoogle WorkspaceOther IMAP providers — YesMicrosoft 365Google WorkspaceYes — Google Workspace migrationYesMicrosoft 365Other IMAP providers — YesZoho MailGoogle Workspace or Microsoft 365Yes — one-click migrationYesZoho MailOther IMAP or POP providers — YesZoho MailOn-premises Exchange or PST filesYes — Exchange Migration Wizard —

Moving to Google Workspace

Google’s main route is the data import tool in the Google Admin console. It can import from Microsoft Exchange Online, IMAP-based webmail providers, another Google Workspace account, or a personal Gmail account, and it must be run by a super administrator.

For Microsoft 365 sources, the default import brings across email, calendar and contact data, and handles up to 1,000 users per import — larger organisations run additional imports.

Two details are worth knowing before you start. First, the import copies data rather than moving it, so nothing is deleted or altered in the old Microsoft 365 mailboxes. The old system stays intact as a fallback until you decide to close it. Second, not every Exchange Online feature is supported. Google publishes a list of what is and isn’t imported, and it’s worth reading before promising users that everything will arrive.

For on-premises Exchange servers or more involved scenarios, Google also offers Google Workspace Migration for Microsoft Exchange (GWMME), a desktop tool that can migrate email, calendar and contact data from Exchange, and email from IMAP servers.

The tool itself is the straightforward part. The work around it — mapping users, setting up aliases and groups, deciding what not to migrate, and planning the cutover — is typically where a Google Workspace partner in Kerala adds value.

Moving to Microsoft 365

From Google Workspace, Microsoft provides a dedicated migration path that moves users in batches, so the project can be staged rather than done all at once. A few behaviours are worth planning for:

  • Mail rules migrate but arrive switched off. Microsoft advises users to review them in Outlook before turning them back on.
  • There’s a default message size limit. The largest single message that can be migrated is 35 MB by default, and Microsoft documents how to raise it.
  • Retention and archiving policies should be paused first. Microsoft’s migration tooling doesn’t recognise items that these policies delete or archive during migration, so they get flagged as missing. Microsoft describes this as perceived rather than actual data loss, but it makes genuine gaps much harder to spot, and it recommends disabling such policies before migrating.

From other providers via IMAP, the limits are tighter. Only mail folders are migrated — no contacts, calendar items or tasks. There’s a maximum of 500,000 items per mailbox, migrated newest first. And mailboxes must be created in Microsoft 365 before migration starts, because IMAP migration doesn’t create them.

Microsoft also points customers to its FastTrack programme for migration help. For most small and mid-sized businesses, though, the practical work sits with whoever configures the tenant — preparing it, handling DNS, running batches and verifying the result — which is where a Microsoft partner in Kerala typically comes in.

Moving to Zoho Mail

Zoho offers three routes, depending on where you’re coming from.

One-click (app-based) migration is available only when the source is Google Workspace or Microsoft 365. An administrator authorises Zoho to access the old account, and email, calendar and contacts are migrated together.

IMAP migration is Zoho’s recommended method for other providers. It runs server to server and preserves folder structure and read or unread status, so users pick up where they left off. If the old provider doesn’t support IMAP, POP migration is the fallback. Both bring across email only; calendars and contacts need a separate import.

The Exchange Migration Wizard covers on-premises or hosted Exchange and offline PST files, and can migrate email, calendar, contacts, tasks and notes.

Two practical points apply across all three routes. User accounts must exist in Zoho Mail before migration begins. And for calendar migration from Microsoft 365, the domain in Zoho Mail must match the domain in Microsoft 365, with every user created first.

Zoho also supports coexistence: running Zoho Mail alongside an existing Microsoft 365 or Google Workspace setup on the same domain during a staged migration. Users who have already moved work in Zoho Mail while the rest continue on the old service.

For businesses moving to Zoho Mail as part of a wider Zoho rollout — CRM, Books or Zoho One — a Zoho partner in Kerala can plan the email move alongside the rest of the implementation rather than as a separate project.

Leaving Microsoft 365? Check This Before You Set Dates

This one is time-sensitive.

Microsoft is retiring Exchange Web Services (EWS) — an older interface that many third-party tools use to read Exchange Online mailboxes. Starting 1 October 2026, any Microsoft 365 tenant that hasn’t explicitly configured its EWS setting has EWS switched off, which blocks EWS for all applications in that tenant. EWS is then permanently shut down on 1 April 2027. In between, Microsoft provides an allow-list so administrators can keep specific approved applications working.

This matters for migrations out of Microsoft 365, because some migration tools read the source mailboxes through EWS. Zoho’s own documentation, for example, states that its Microsoft 365 migration currently uses EWS, including for in-place archive mailboxes.

Practical steps before scheduling a move away from Microsoft 365:

  • Ask your migration provider which interface their tool uses to read Microsoft 365 mailboxes.
  • If it uses EWS, check with your Microsoft 365 administrator whether EWS is enabled on your tenant and whether the tool’s application is on the allow-list.
  • If the migration will run past 1 April 2027, confirm the tool works without EWS entirely.

None of this makes leaving Microsoft 365 impossible. It does mean the date you pick, and the settings on the old tenant, now matter.

The Cutover: Order of Operations

Whichever direction you’re moving, the sequence that keeps mail flowing is broadly the same.

  1. Create every user account on the new platform first — including aliases, groups and shared addresses. Google’s guidance is to create user accounts, mailing lists and nicknames before changing MX records, to avoid bounced mail. Zoho and Microsoft’s IMAP route both require accounts to exist before migration starts.
  2. Copy historical data while the old system is still live. Run the bulk migration before the switch, so the cutover itself only has to handle recent mail.
  3. Change the MX records. These tell the internet where to deliver your domain’s email. Google notes that MX changes can take up to 48 hours to propagate, and that until they do, mail continues to arrive at your previous provider.
  4. Keep the old mailboxes running through propagation, then run a final sync to catch anything that landed at the old provider during the switch.
  5. Update your email authentication records — SPF, DKIM and DMARC — to match the new provider, so outgoing mail isn’t treated as suspicious.
  6. Reconnect devices. Phones and desktop email apps generally need to be set up again against the new service.
  7. Only then close the old service — after users have confirmed their mail, calendars and contacts are where they expect.

What Tends to Go Wrong

  • Calendars and contacts left behind because an IMAP method was used where a native tool was available.
  • Shared mailboxes, aliases and groups forgotten. These often need separate setup and don’t always come across with individual mailboxes.
  • Mail rules that quietly stop working — in Microsoft’s case, they arrive switched off.
  • Items that appear to be missing because retention or archiving policies were left active during migration.
  • Oversized messages that exceed the destination’s migration size limit.
  • MX records changed before accounts existed, causing bounced mail.
  • The old service closed too early, before the final sync and user checks.

Pre-Migration Checklist

  • Which migration method does our source-and-destination combination support — native, IMAP, or both?
  • Do we rely on shared calendars or company-wide contacts that IMAP won’t carry?
  • Are all users, aliases, groups and shared mailboxes listed and ready to create?
  • Are retention or archiving policies active on the source that should be paused?
  • If leaving Microsoft 365, does our migration tool depend on EWS, and is it allowed on our tenant?
  • Who controls the domain’s DNS settings, and when exactly will MX records change?
  • How will staff be told what to do on switch-over day?
  • When, and on whose sign-off, will the old service be closed?

Frequently Asked Questions

Q: Will we lose email during the switch?

Not if the steps are sequenced properly. While MX records propagate, incoming mail keeps arriving at the old provider — which is exactly why the old mailboxes stay live until a final sync has run.

Q: How long does a migration take?

It depends on the number of users, mailbox sizes, the migration method and how much preparation has been done. There’s no reliable standard figure. Get an estimate after the mailboxes have been assessed, not before.

Q: Can we move people in stages rather than all at once?

Yes. Microsoft’s migration from Google Workspace runs in batches, and Zoho’s coexistence feature lets part of an organisation use Zoho Mail while the rest stays on the old service during the transition.

Q: If we change our minds, is the old data still there?

Generally yes, until you close the old accounts. Google’s import from Microsoft 365, for example, copies data without deleting or altering it at the source. Don’t close the old service until you’re certain.

Q: Do staff need to do anything?

Usually: reconnect phone and desktop email apps, check any mail rules, and confirm their calendars and contacts look right.

Final Thoughts

Google, Microsoft and Zoho all provide capable migration tools. Whether a move is smooth or disruptive is mostly decided before any tool runs: choosing a method that carries the data you actually need, creating accounts before touching DNS, keeping the old system alive until the final sync, and — this year in particular — checking whether a Microsoft 365 exit depends on EWS.

If you’re weighing a move between any of these platforms, our team at Techgeum works across all three, so our recommendation isn’t tied to any single vendor.