Google Workspace to Zoho Workplace Migration Guide

Why This Decision Keeps Getting Deferred

Most businesses that are paying too much for email know they are paying too much for email. The invoice arrives annually, the per-user figure has gone up again, and somebody says out loud that it is a lot of money for what is essentially mail and a calendar.

Then nothing happens, for a reason that has little to do with cost. Email is the one system where failure is immediately visible to everybody, including customers. A botched finance migration is embarrassing internally. A botched email migration means a sales director cannot find a thread from eighteen months ago in front of a client, and that gets remembered.

So the decision stalls, not because the alternative is unconvincing, but because nobody has written down what would actually happen. This article does that. It covers what Zoho Workplace includes, which migration method applies to your situation, what data moves and what demonstrably does not, and where the real risk in the project sits. It is written for whoever would own the project: an IT manager, a founder, or a finance director who has looked at the renewal and started asking questions.

The Business Problem: A Cost That Only Goes One Way

Three things tend to be true at once in businesses that start looking at this.

The licence count has drifted upward and never downward. Leavers’ accounts are kept “just in case”, shared mailboxes are licensed as users, and contractors who finished a project two years ago are still on the bill. Nobody owns the list, so nobody prunes it.

The tier was chosen once and never revisited. An upgrade was bought for a feature two people needed (archiving, a compliance control, extra storage), and it was applied to everybody, because that is how per-seat licensing works.

Actual usage is narrower than the licence implies. The suite includes a dozen applications. Most organisations use mail, calendar, files and some video calling. The rest is paid for and dormant.

None of this is an argument that the incumbent is a bad product. It is an argument that the cost is no longer being tested against the use. And in a business of fifty to three hundred people, that gap is usually a meaningful annual number, which is why the finance director is often the person who raises it, not IT.

What It Actually Costs You to Defer

Worth being precise here, because the cost of inaction is not only the licence fee.

• The direct cost compounds. Per-user pricing multiplied by headcount growth multiplied by annual increases is a line item that grows faster than the business does.
• The waste is invisible in the accounts. Dormant accounts and over-specified tiers do not appear as waste anywhere. They appear as “software”, and software is expected to go up.
• The switching cost rises with time. Every additional year of mail history makes the migration larger and slower. Waiting does not make this project easier.
• Fragmentation accumulates at the edges. When the suite is expensive, teams buy cheaper point tools for file sharing, chat or signatures rather than adding seats, so the business ends up paying for the expensive suite and, on top of it, a scattering of subscriptions nobody tracks.

What Zoho Workplace Is

Zoho Workplace is Zoho’s bundled productivity suite. Zoho’s own product page lists Zoho Mail, Zoho Calendar, Zoho Cliq for team messaging, Zoho Meeting for video conferencing, Zoho WorkDrive for file storage and sharing, and the Writer, Sheet and Show editors for documents, spreadsheets and presentations. Zoho Connect for employee engagement and a password manager appear alongside the core list, and the list is explicitly open-ended.

Desktop clients for macOS and Windows are listed as included with subscriptions for Mail, Calendar, Writer, Sheet, Cliq, Meeting and WorkDrive Sync. That is worth noting, because “web only” is a common and incorrect assumption about Zoho’s office tools.

Two practical points matter more than the app list.

The editors open your existing files. Zoho describes its office applications as working with existing Word, Excel and PowerPoint files. For most businesses the question is not whether the editors are as capable as the incumbent’s (for heavy spreadsheet modelling, they may not be), but whether the files people actually exchange open, edit and return correctly. That is a question to answer with your own documents during the pilot, not from a feature list.

Workplace is not Zoho One. Workplace is the productivity suite. Zoho One is the much broader bundle that includes CRM, finance and the rest of the business applications. Businesses frequently conflate them and then compare the wrong price to the wrong thing. If the goal is replacing email and documents, Workplace is the comparison. If the goal is consolidating the whole application estate, that is a different and larger conversation.

The Four Migration Methods, and When Each One Applies

Zoho’s admin console documentation sets out several migration routes. Choosing the right one is most of the project risk.

One-Click (App-Based) Migration

You authorise Zoho to access the source mailboxes directly. Zoho’s documentation states this method is currently supported for Google Workspace and Microsoft 365. It is the least manual route and the natural first choice when you are coming from either of those two platforms.

IMAP Migration

A server-to-server transfer, and the method Zoho’s own documentation recommends most strongly. It preserves folder structure and read/unread status, which sounds minor and is not. A migration that dumps fifteen years of filed mail into a single inbox will be treated by your users as data loss, regardless of what the technical report says.

POP Migration

The fallback where IMAP is unavailable. The documentation is explicit about its limitations: folders are not preserved and all mail lands in the inbox, everything arrives marked unread, mail sent from other clients is not migrated, and failures are difficult to trace. Treat POP as a last resort for a small number of awkward accounts, not as a plan for an organisation.

Exchange, EWS and the Zoho Exchange Migration Wizard

For organisations coming off an Exchange server, migration runs over Exchange Web Services or through Zoho’s Exchange Migration Wizard. The wizard also handles PST and EML archives and Active Directory synchronisation. One documented constraint matters: Exchange migration can only be performed by administrators, and the Exchange route through the wizard moves email only.

What Moves, and What Does Not

This is the section to read twice, because the answer depends entirely on the method, and the differences are not intuitive.

Three consequences follow, and planning for them is the difference between a smooth project and a difficult fortnight.

If you migrate mail by IMAP, plan contacts and calendars separately. Zoho’s documentation describes IMAP in terms of mail and folders. Contacts and calendars are not documented as part of that transfer. For most businesses this means an export and import step, scheduled deliberately rather than discovered on cutover day.

Shared and delegated mailboxes need their own plan. Shared mailboxes, delegated access, distribution groups and aliases are configuration, not mailbox content. They do not travel with the mail. Inventory them before you start, because a sales@ address that stops routing on Monday morning is the kind of failure that defines a project.

Throughput is slower than people expect. Zoho’s documentation gives an indicative figure of around eleven hours for twenty-five users holding roughly two gigabytes each, at a connection limit of ten. It also notes that some source servers begin throttling IMAP fetches after a period. Scale that to your own user count and mailbox sizes before you promise anyone a weekend cutover.

The Part Everyone Underestimates: The MX Cutover

Changing the MX record is the moment mail delivery moves. It is a single DNS change, which is why it gets treated as trivial, and it is where most of the avoidable pain lives.

The sequence that matters:

• Mail delivered before the MX change must be re-migrated. Any message that arrives at the old platform after your initial migration pass and before the cutover is sitting in the old system. Zoho’s documentation addresses this (duplicates are handled), but the delta pass has to be planned, not remembered.
• Plan the change for a low-traffic window. Zoho’s documentation suggests a weekend. The reason is not technical difficulty but blast radius: you want the quiet period for discovering whatever you missed.
• Consider email routing and a catch-all during transition. Both are mentioned in Zoho’s guidance, and both exist to stop mail falling into a gap while DNS propagates and stragglers are resolved.
• Split delivery is available if you need it. Zoho’s Workplace page describes split delivery, where part of the organisation moves while the rest stays with the current provider. For a large or cautious migration this converts one high-risk event into several lower-risk ones. It adds complexity in exchange for recoverability, which for a business where email failure is customer-visible is usually a trade worth making.

Planning the Migration

Before You Touch Anything

• Audit the licences first, and do it properly. Every account, with a named owner, a last-login date and a decision: migrate, archive, or close. This exercise frequently changes the business case on its own, because the first discovery is usually how many licences are not people.
• Inventory the configuration, not just the mailboxes. Aliases, distribution groups, shared mailboxes, delegated access, forwarding rules, auto-replies, mobile device policies, and every third-party service that authenticates through the current identity provider. That last one catches people out: single sign-on into unrelated applications may be tied to the suite you are leaving.
• Measure the data. Number of mailboxes, size of each, and the size of the largest. The eleven-hour figure above scales with both, and your migration window is determined by the largest mailbox as much as by the total.
• Decide what is archived rather than migrated. Not every mailbox needs fifteen years of history in the new system. Leavers’ mail, closed projects and dormant accounts can go to archive. Less data means a shorter migration and a cheaper subscription. This decision has records-retention implications, so take it with whoever owns that policy. If you operate in the UAE, our guide to UAE record retention requirements sets out the periods involved.
• Confirm your data residency position. Where the data physically sits may matter to your customers, your regulator or your contracts. Zoho operates multiple data centres, and the choice is made at setup rather than changed later. We have covered this specifically for the region in our note on Zoho UAE data centres and data residency.

The Pilot

Zoho’s documentation recommends a sample migration before the full run. Its own guidance gives two different ranges (three or four users in the step list, two to ten in the best practices), so take the range that fits your organisation and be guided by coverage rather than by the number.

Choose pilot users for difficulty, not for seniority. You want the largest mailbox, the person with the most elaborate folder structure, somebody who relies on shared mailbox access, and somebody who works primarily from a phone. A pilot of four cooperative users with tidy inboxes tells you almost nothing.

The Main Run and the Follow-Through

Migrate in batches by team, so that when something is wrong, the people affected sit near each other and can be supported together. Run the delta pass. Change MX. Keep the old platform live and paid for a defined period afterwards (a month is a reasonable default), and diarise its cancellation, because an un-cancelled parallel subscription quietly eats the saving the project was for.

Best Practices

1. Do the licence audit before the migration plan. It changes both the scope and the business case.
2. Use IMAP or one-click. Avoid POP for anything but an edge case, and tell anyone migrated by POP what to expect.
3. Inventory aliases, groups, shared mailboxes and delegated access separately from mailboxes. They are the most common cause of a visible failure.
4. Pilot with your hardest cases, not your most patient colleagues.
5. Run the delta pass immediately before the MX change, not the day before.
6. Set the data centre deliberately at setup, with your data residency obligations in front of you.
7. Communicate twice to users: once a week ahead explaining what will change, and once on the day explaining what to do if something is missing. Give them a named person to ask.
8. Keep the old platform for a defined overlap period, and diarise cancelling it.
9. Test on phones before you declare success. Most complaints after an email migration are mobile reconfiguration, not data.
10. Decide archiving policy before migrating, not after you have paid to move data you did not need.

Common Mistakes

• Treating the MX change as the project. It is the last five minutes of the project. The work is everything before it.
• Migrating every mailbox because it is easier than deciding. This is how a cost-reduction project arrives with no cost reduction.
• Forgetting third-party single sign-on. Applications that authenticate through the outgoing identity provider need their own plan, and they are usually discovered by a user who cannot log in.
• Assuming contacts and calendars come with the mail. For IMAP, they are not documented as doing so.
• Underestimating throughput. Promising a Saturday cutover for three hundred mailboxes and discovering the throttling limit at two in the morning.
• Skipping the pilot, or running a flattering one.
• Leaving the old subscription running indefinitely. Common, expensive, and entirely avoidable with a calendar entry.
• Comparing Workplace to Zoho One. Different products, different prices, different decision.
• Not briefing the front line. Reception and sales notice a mail problem before IT does, and they should know who to tell.

An Illustrative Scenario: A 90-User Services Business

The following is a composite illustration assembled from patterns common to migrations of this size. It is not an account of a specific Techvaria client, and no figures below are drawn from any real engagement.

Consider a professional services business of around ninety staff across two offices, on a major productivity suite for several years, with a renewal approaching and a finance director who has asked why the line has grown faster than headcount.

What the audit finds. The licence count is higher than the headcount. Several accounts belong to people who left. A handful of shared addresses (info@, careers@, a project alias) are licensed as full users. A premium tier was applied organisation-wide some years ago for an archiving feature that two people in compliance use. Mailboxes range from under a gigabyte to one partner holding considerably more than anyone expected.

What the inventory finds. Four shared mailboxes with delegated access, eleven distribution groups, two external applications that authenticate through the current identity provider, and a departmental auto-reply nobody remembers configuring.

How it is planned. Dormant accounts are archived rather than migrated, which reduces both the data volume and the eventual subscription. Mail moves by IMAP so folder structure and read state survive. Contacts and calendars are planned as an explicit, separate step rather than assumed. The pilot runs with the largest mailbox, the most heavily foldered user, one shared-mailbox dependant and one phone-first user. The main migration runs in batches by team across a fortnight, with a delta pass and a weekend MX change, and split delivery held in reserve for the second office.

What goes wrong, because something does. The external applications using single sign-on are the issue, as they usually are. They are found during the pilot rather than on cutover weekend, which is the entire purpose of a pilot.

What the business ends up with. A licence count that matches its actual people, a tier that matches actual use, and an archiving decision taken deliberately. The saving comes substantially from the audit, not from the platform change, which is the most common and least expected outcome of this project.

Industry Use Cases

Professional services and consultancies. Mail is itself the record of the client relationship, so folder structure and historical search matter more than in most sectors. IMAP’s preservation of folders is the deciding factor. See our work in professional services.

IT services and technology firms. Usually the most straightforward technically and the most exposed to single sign-on dependencies, because they have more integrated applications than anyone. See IT services and ERP.

Trading and distribution. Shared mailboxes carry the operational load here (orders@, shipping@, accounts@), and these are the accounts where a routing failure is felt within the hour.

Manufacturing. Lower mailbox counts relative to headcount, because shop-floor staff are often unlicensed, which is why the licence audit frequently finds the largest proportional saving here. Education has the advantage of term dates, which provide natural low-traffic cutover windows.

Migration Methods Compared