Google Workspace to Microsoft 365: Why Labels Expand Storage

The short answer: a Google Workspace to Microsoft 365 migration is not a "copy the mailbox" job. Gmail labels aren't folders, and everything else in Workspace, Calendar, Contacts, Drive, Groups, moves on a completely separate path from mail. Get the label-to-folder conversion and the DNS cutover right and the rest is admin. Get them wrong and you get duplicate mail, missing calendars, and a mailbox that's mysteriously twice the size it was in Gmail.

Why does a 20GB Gmail mailbox turn into something bigger in Exchange?

This is the single thing that catches people out mid-migration, so it needs saying early rather than discovered at 2am when a sync stalls. Gmail doesn't use folders the way Exchange or Outlook does. A message can carry the "Work", "Invoices" and "Follow-up" labels at once, sitting as one physical copy inside Google's storage model. Exchange has no concept of a message living in three places simultaneously. When a migration tool converts labels to folders, it typically creates a separate copy of the message for each label applied to it.

Practically, that means a mailbox showing 20GB in the Google admin console can expand considerably once every label becomes its own folder copy in Exchange. I've had clients budget storage and migration windows off the Gmail number, then watch the sync run long and eat into Exchange Online quota faster than expected. Plan storage and timing off the worst case, not the Gmail figure, and run mailboxes through something like the email migration checker before you commit to a cutover window so you're not guessing.

What actually moves with the mail, and what needs its own migration?

People assume "migrate Gmail to Outlook" means everything comes across in one pass. It doesn't. Mail, and only mail, moves through a mailbox migration. Google Calendar and Google Contacts have their own export and import paths, generally CSV or ICS exports on the Google side and separate import steps into Exchange Online or Outlook. Run only the mail migration and call it done, and users will open Outlook to an empty calendar and wonder where their meetings went.

Google Drive and shared drives are a different project entirely. They're file storage, not mail, and they sit outside the scope of any mailbox migration tool regardless of vendor. Moving Drive content into SharePoint or OneDrive is a separate migration with its own tooling, permissions mapping and timeline. Conflating the two is the most common source of confusion I see in these projects, usually because someone assumed "migrate everything" meant one tool did all of it. It doesn't. Scope mail, calendar, contacts and Drive as four separate workstreams even if they run in parallel.

How do Google Groups map to Microsoft 365, and where does it go wrong?

Google Groups don't map cleanly onto a single Microsoft 365 concept. Depending on how a group was used in Workspace, it might need to become a distribution list, a shared mailbox, or a Microsoft 365 group, and each behaves differently for permissions, sending, and archive access. A group used purely for mass internal email usually becomes a distribution list. A group people expected to log into and read collectively, the way a shared inbox works, needs a shared mailbox instead, since a plain distribution list has no shared storage of its own.

Get this mapping wrong and you find out weeks later, when someone asks why they can no longer see the group's email history, or why replies aren't reaching everyone who used to be on the list. Map every Google Group to its Microsoft 365 equivalent before cutover, not after, and document who owns each one in the new tenant.

Should you use Microsoft's native migration tools or a third-party IMAP sync?

Microsoft's own tooling for pulling mail from Google Workspace into Exchange Online works, and it's the option most Microsoft partners push first because it talks to Google's IMAP endpoint directly, with Microsoft handling the batch scheduling. Microsoft's mailbox migration documentation covers the current setup steps, and because Microsoft updates this UI regularly, that page is the authority, not a screenshot from a blog post written months ago.

Third-party IMAP migration tools are the alternative, and they're often the better fit for smaller Workspace tenants, or when you want granular control over label-to-folder mapping, filtering out specific labels, or staging the migration mailbox by mailbox rather than in one Microsoft-managed batch. Neither option is universally better. Native tooling tends to win on scale and support; third-party tools tend to win on flexibility. Whichever you choose, read Microsoft's migration advice first, because it lays out the batch and throttling considerations that affect timing regardless of tool.

How do app passwords and OAuth affect the connection to Gmail?

Whatever tool you use, it needs to authenticate against the Gmail account to pull mail, and Google has moved firmly away from plain username-and-password IMAP access. You'll be setting up either an app password on accounts with basic IMAP enabled, or configuring OAuth through a Google Cloud project registered against the Workspace domain, depending on what your migration tool supports. Google's admin help covers current requirements for enabling IMAP access and authentication at the domain level, worth checking before you start, because a tenant with IMAP disabled by policy will block the sync at the first mailbox and waste the morning you set aside for it.

How do you avoid duplicate mail from Gmail's All Mail folder?

Gmail's All Mail is effectively a view of every message in the account, including ones already sitting in Inbox, Sent, and every label folder. If your migration tool isn't configured to exclude All Mail from the sync, it will happily migrate every message twice: once from its label folder, once again from All Mail. This is one of the more avoidable mistakes in a Gmail to Outlook migration, and it's purely a configuration step, not a limitation of the tooling. Check the folder exclusion settings before the first batch runs, not after users start complaining about duplicate emails in every folder.

What's the correct order for the MX, SPF, DKIM and DMARC cutover?

This is where a Google Workspace to Microsoft 365 migration becomes a DNS exercise as much as a mail one, and it's genuinely easy to get the sequence wrong. Run a MX record lookup first to confirm your current setup, then work through this order rather than flipping everything at once.

Publish Microsoft's DKIM selectors alongside Google's existing ones before you touch anything else. DKIM signing doesn't need mail to have stopped flowing through Google, and getting Microsoft's selectors live early means outbound mail can be signed correctly the moment you cut over sending. Use a DKIM generator to build the records and check the DNS glossary entry if any of the record types are unfamiliar to whoever's making the changes.

Next, update SPF to include Microsoft's sending infrastructure while Google's include is still live, because during the transition both platforms may be sending mail for your domain, and SPF needs to authorise both. This is exactly where the ten DNS lookup limit in SPF bites people: two full mail platform includes plus any existing third-party senders can push a domain over the limit fast, causing SPF to fail entirely rather than partially. Run the change through a SPF generator that flags lookup count, and read the MX record glossary entry if you're unclear on how MX and SPF interact, because they don't do the same job, and confusing them is a common source of misconfigured records.

Only once DKIM is publishing correctly and SPF includes both platforms should you make the actual MX change to point at Microsoft's endpoint. Mail delivery follows MX immediately, so this is the point of no return for inbound mail, and it should be the last domain change you make, not the first. Once mail is flowing through Microsoft, tighten up with a DMARC generator so spoofed mail using your domain gets rejected or quarantined rather than silently accepted, worth doing regardless of which platform you're on.

For the general shape of this sequencing outside the Google-to-Microsoft specifics, our email migration guide and the accompanying email migration checklist cover the steps that apply whichever platforms are involved.

What will your team actually notice and complain about?

Be honest with people rather than pretending the switch is invisible, because it isn't. Gmail's search is genuinely good, and people rely on it more than they realise, searching by sender, label and date range in ways Outlook search doesn't replicate the same way out of the box. Gmail filters also don't migrate automatically. Anyone with carefully built filters routing newsletters, invoices or specific senders into labels will find those rules gone on day one in Outlook, and they'll need rebuilding as Outlook rules rather than assuming they came across with the mail.

Tell people this before cutover, not after. A short note explaining that search will feel different and filters need rebuilding saves a week of support tickets that all say the same thing. If your domain sits behind a registrar-managed setup, our piece on GoDaddy Microsoft 365 Alternatives for Personal Domains covers some of the domain-side quirks worth knowing before you touch DNS, and if this migration is happening alongside a wider infrastructure change, Site Migration Without Losing SEO: The Host-Only Plan is useful reading for keeping the rest of your stack stable while mail moves.

Frequently asked questions

Can you migrate Gmail to Outlook without losing email history?

Yes, mail history migrates in full through either Microsoft's native tooling or a third-party IMAP sync, but calendar and contacts don't come across with it and need separate export and import steps. "Without losing anything" only holds if you scope all four workstreams, not just mail.

How long does a Google Workspace to Microsoft 365 migration take?

It depends heavily on mailbox count, total data volume including the label-to-folder expansion, and which tool you're using. Microsoft's own migration advice covers the batching and throttling factors that affect timing, so there's no fixed figure that applies across tenants. Test with a small batch first rather than committing every mailbox to a single migration window.

Do Google Groups become Microsoft 365 Groups automatically?

No, there's no automatic mapping. Each Google Group needs to be manually assessed and mapped to a distribution list, shared mailbox or Microsoft 365 group depending on how it was actually used, and doing this after cutover rather than before is how groups lose their shared history.

What happens to SPF and DKIM during the transition period?

Both Google's and Microsoft's records need to be live at once while mail may be sending from either platform, which means SPF needs includes for both and DKIM needs both sets of selectors published. This dual-include period is exactly when domains commonly exceed the ten DNS lookup limit and start failing SPF checks entirely.

Final thoughts

The mechanics of a Google Workspace to Microsoft 365 migration are well documented by both vendors, and the vendor docs should be your source of truth for the current UI rather than a screenshot-heavy blog post. What actually determines whether the migration goes smoothly is the label expansion planning, the Calendar, Contacts, Drive and Groups scoping done as separate workstreams, and a DNS cutover sequenced correctly rather than flipped all at once. Get those right and the rest is a checklist, not a crisis.