Migrating from Google Workspace to Microsoft 365: A Complete Guide

Companies move from Google Workspace to Microsoft 365 for all kinds of reasons: a merger with a Microsoft shop, a client base that lives in Outlook and Teams, licensing consolidation, or simply a leadership preference. Whatever brought you here, the good news is that this is a well-trodden path with mature tooling. The less good news is that Google and Microsoft model email, calendars, and files differently enough that a careless migration leaves users with mangled folders, broken recurring meetings, and a Drive full of orphaned documents.

This guide walks through the whole move in phases, calls out the real quirks we plan around, and explains where a specialist earns their keep.

What actually moves, and what does not

Start by being precise about scope, because "migrate us to Microsoft 365" hides several separate workstreams:

• Mail, calendar, and contacts migrate through purpose-built tooling. Microsoft provides a Google Workspace migration path in the Exchange admin center that connects to your Google tenant via a service account and pulls mailbox data across in batches.
• Drive content (My Drive and shared drives) is a separate workstream entirely, landing in OneDrive and SharePoint respectively. It has its own tooling, its own permission-mapping problems, and usually its own timeline.
• Google-native file formats (Docs, Sheets, Slides) must be converted to Office formats on the way over. Complex spreadsheets with Apps Script automation do not convert; they need to be identified and rebuilt or retired.
• Chat history, Sites, Forms, and Keep generally do not migrate in any first-class way. Plan an export-and-archive strategy for anything you are required to retain.

Getting agreement on this scope before anyone touches a tool prevents the most common post-migration complaint: "where did X go?" The answer should always be decided in advance, never discovered afterward.

Phase 1: Discovery and tenant preparation

Before any data moves, we build an inventory: every user, every shared mailbox equivalent (in Google, often a group or a delegated account), every calendar resource (rooms, equipment), every group and its membership, and the domains attached to the Workspace tenant. On the Microsoft side, that inventory drives:

1. Tenant setup and domain verification. Your domain is added and verified in Microsoft 365 while MX records still point at Google. Mail keeps flowing to Gmail untouched.
2. Identity decisions. Will users sign in with cloud-only Microsoft Entra accounts, or sync from an existing directory? Usernames should match their Google addresses to keep the cutover simple.
3. Licensing. Mailbox sizes in Google inform plan selection in Microsoft 365. Most business plans include a 50 GB mailbox; heavier users may need enterprise-class plans. Our post on mailbox and item limits in Microsoft 365 covers this in detail.
4. Google-side prerequisites. The migration tooling needs a Google service account with domain-wide delegation and specific API scopes enabled. This is fiddly, poorly documented in places, and the single most common reason a first migration batch fails to connect.

Phase 2: The label problem, and other translation quirks

Gmail does not have folders. It has labels, and a single message can carry several of them. Exchange Online has folders, and a message lives in exactly one. The migration tooling translates labels into folders, which means a message labeled both Clients and Invoices has to end up somewhere specific, and the result can surprise users: duplicated messages across folders in some tooling, or a message filed under only one of its labels in others.

Other translation quirks worth planning for:

• Nested labels become nested folders, but labels with characters that are illegal in folder names get renamed.
• Recurring calendar events mostly translate cleanly, but exceptions to a series (that one moved meeting in a weekly recurrence) are a classic source of drift. Room bookings tied to Google resource calendars need those resources recreated in Exchange Online first.
• Contact groups and delegated mailbox access do not carry over automatically; they are rebuilt on the Microsoft side from the discovery inventory.
• Vacation responders, filters, and forwarding rules stay behind in Gmail. Users recreate the ones they need in Outlook, and we flag any forwarding rules that route mail outside the company, since those deserve a security review anyway.

None of these are dealbreakers. All of them are the difference between a migration that feels seamless and one that generates a week of confused tickets.

Phase 3: Pre-staging the data

The Google Workspace migration path in Microsoft 365 supports running batches while users keep working in Gmail. We take advantage of that by pre-staging: the bulk of every mailbox is copied to Exchange Online days or weeks before cutover, while Google remains the live system. Large tenants get split into batches, and throughput is governed by Google API quotas as much as by Microsoft throttling, so realistic scheduling matters. A 40-mailbox company might pre-stage in a couple of nights; a 400-mailbox company needs a calendar, not an evening.

Pre-staging also surfaces problems early: mailboxes that exceed quota on the target plan, items too large to migrate, and connection errors from misconfigured delegation, all found while there is still time to fix them calmly.

Phase 4: Cutover

Cutover is the coordinated moment when Microsoft 365 becomes the live system:

The Google lockdown step is the one inexperienced teams skip. If Gmail stays fully usable after cutover, some users will keep living in it, and mail history splits across two systems. Read-only access for a defined wind-down period is the usual compromise.

Phase 5: Drive, and the long tail

File migration usually trails mail by design. My Drive content maps to each user's OneDrive; shared drives map to SharePoint sites or Teams. The hard part is permissions: Google's sharing model ("anyone with the link," domain-wide sharing, individual grants) has to be translated into SharePoint's model without either locking people out or overexposing documents. We map the top-shared content first, migrate in waves, and run both systems in a read-only overlap so nothing is lost mid-edit.

The long tail after any Google-to-Microsoft move includes retraining (Outlook search behaves differently from Gmail search, and users notice), rebuilding integrations that authenticated with Google, and tuning the new tenant's security posture. That last item matters enough that we wrote about it separately: see why managed Office 365 matters after the migration.

What a specialist changes

A generalist IT team can absolutely move mail from Google to Microsoft. What a migration partner changes is the error rate at the edges: the service-account scopes that fail silently, the label translation policy chosen deliberately instead of discovered accidentally, the resource calendars rebuilt before recurring meetings break, the MX cutover timed against TTLs that were lowered a week earlier, and the Drive permission map reviewed before ten years of documents go public to the whole company. We have run this exact move enough times that the surprises are on our checklist rather than in your inbox. If your situation includes wrinkles like an IMAP archive or old PST exports alongside Workspace, see our guides to IMAP and legacy migrations and PST files.