Migrate Google Workspace to Microsoft 365: A Complete Enterprise Migration Guide

Why Companies Migrate G Suite to Office 365?

• A merger or acquisition where the acquiring company standardizes on Microsoft 365.
• Contractual or procurement decisions made at the enterprise level that leave IT with a deadline, not a debate.
• A push toward integration with Windows endpoints, Active Directory, or existing on-premises infrastructure.
• Compliance or security requirements that map more cleanly to Microsoft Purview, Defender, and Entra ID.

What Actually Has to Migrate from Google Workspace to Office 365?

A Google Workspace to Microsoft 365 migration touches several independent systems, and each one maps to a different Microsoft 365 service:

Google Workspace	Microsoft 365 destination	What needs to survive the move
Gmail	Exchange Online	Messages, attachments, folder structure, labels mapped to folders, read/unread status
Google Contacts	Exchange Online / Outlook	Names, emails, phone numbers, company fields
Google Calendar	Exchange Online / Outlook	Events, recurring series (RRULE data), attendee lists
Google Drive (including Shared Drives)	OneDrive / SharePoint	Folder hierarchy, file versions, sharing permissions, ownership
Google Tasks	Microsoft To Do / Outlook Tasks	Microsoft To Do / Outlook Tasks Task lists and due dates

Pre-Migration Checklist

A short list of confirmations before the first batch runs saves most of the mid-project surprises:

• Global admin access confirmed on both the Google Workspace and Microsoft 365 tenants.
• Microsoft 365 licenses provisioned and mailboxes created for every user ahead of time.
• Required Google and Microsoft Graph APIs enabled and authenticated.
• Destination tenant storage (OneDrive or SharePoint) has enough headroom for the incoming Drive and mailbox data.
• A user mapping (source email to destination email) built and reviewed in advance, not improvised during the run.
• Users notified of the migration window and any expected downtime.
• A rollback or fallback plan in case a batch needs to be paused.

The Real Obstacles Teams Run Into

A handful of problems show up on nearly every Google-to-Microsoft migration of meaningful size:

• Two completely different data models: Gmail organizes mail with labels, which can apply to a single message multiple times. Exchange Online organizes mail with folders, where a message lives in one place. Every label-to-folder mapping decision affects how familiar the inbox feels to the end user afterward.
• Drive-to-SharePoint permission drift: Google Drive sharing (link-based, domain-wide, individual) doesn’t translate one-to-one into SharePoint or OneDrive permission models. Migrated files can end up more open, or more locked down, than they were in Drive unless permissions are explicitly mapped rather than assumed.
• Calendar recurrence and external attendees: Recurring events and meetings with attendees outside the organization are the most common casualty of a rushed calendar migration. A method that reads RRULE data and attendee lists as structured calendar objects avoids flattening a recurring series into a handful of disconnected one-off events.
• Authentication and Basic Auth retirement: Microsoft has phased out Basic Authentication for Exchange Online, which means any migration tooling connecting to the destination tenant needs to support Modern Authentication (OAuth 2.0) rather than legacy username/password binding.
• Scale: Migrating 15 mailboxes by hand is tedious but doable. Migrating 1,500 mailboxes by hand isn’t realistic – it requires batch mapping, usually via CSV, plus a way to monitor progress across every batch without babysitting each one individually.
• Interrupted jobs: Network drops, expired OAuth tokens, and API throttling all cause migration jobs to stall mid-run. Whether the tool can resume from the last completed item, or has to start the entire mailbox over, has a real effect on project timelines at scale.

The Manual Path: Exchange Admin Center

Microsoft’s built-in option runs through the Exchange Admin Center (EAC). At a high level:

1. Sign in to the Microsoft 365 admin center and open Exchange.
2. Go to Migration and add a new migration batch.
3. Select Google Workspace (Gmail) migration as the type.
4. Complete the prerequisite steps: enabling the necessary Google APIs (Gmail, Calendar, Contacts, Admin SDK) and installing Microsoft’s migration app from the Google Workspace Marketplace.
5. Authenticate with a Google Workspace super admin account and generate the required JSON credentials.
6. Map source Google users to their Microsoft 365 mailboxes.
7. Start the batch and monitor sync status.

This works well for smaller migrations, but it’s mail-focused. Drive, Tasks, and Keep aren’t part of this flow, and larger batches routinely run into the failure patterns below.

Where Real Migrations Break

A look through Microsoft’s own Q&A forum shows the same failures recurring across unrelated organizations:

• Calendar API disabled throws a permissions error mid-batch that looks unrelated to calendars, until someone checks the Google Cloud console.
• Tokens expiring mid-migration long-running batches on large mailboxes are especially prone to this, eventually causing the job to abandon itself after too many retries.
• Large mailboxes stalling near 10% complete is usually a Google-side API quota limit under sustained load, not a config mistake, so re-running the same batch rarely helps.
• Domain and alias mismatches: a batch can show “complete” while individual users silently fail because of a Google-side alias that doesn’t match Exchange Online’s accepted domains.
• Messages flagged “missing” that aren’t retention or archival policies on the Google side can make migrated messages look lost during verification, when they were just relocated by a policy the migration tool didn’t account for.

The API Ceilings That Shape a Migration Plan

Both platforms enforce limits designed to protect their own infrastructure, and a realistic migration plan is built around them rather than discovered by hitting them.

On the Google side, the Gmail API caps authenticated access at 250 quota units per second per user, with different actions consuming different amounts of that quota. IMAP-based extraction from Google carries its own daily bandwidth ceiling, separate from the API.

Microsoft Graph throttling applies per app, tenant, and sometimes per user – not by license tier, so upgrading plans won’t help. Throttled requests get an HTTP 429 with a Retry-After header. IMAP-based Google migrations cap out at 500,000 items per mailbox, 50,000 mailboxes, and 35 MB per email, so large projects need batching.

Professional Method to Migrate Google Workspace to Microsoft 365

Microsoft’s built-in G Suite migration (via the Exchange admin center). Microsoft ships a native migration type specifically for moving from Google Workspace, built on IMAP under the hood. It’s free, included with an Exchange Online subscription, and works well for mail-only moves of a modest size. Its limitations mirror IMAP’s own: no native path for Drive, Calendar (beyond what free/busy sync tools bolt on), or Tasks, a 35 MB per-message ceiling, and batch mapping that leans on a CSV file capped at 10 MB. It can backup Google Workspace emails data to different email clients and file formats.

A Cigati Google Workspace to Office 365 Migration Tool. Once a project spans mail, Drive, contacts, calendars, and tasks, or crosses more than a couple hundred users. This software typically earns back its cost through centralized authentication, bulk mailbox mapping, filtering, resume-on-failure, duplicate detection, and a completion report that holds up to an audit. It generally authenticates to Google via OAuth 2.0, domain-wide delegation, or a service account JSON/P12 key, and to Microsoft 365 via Graph API with Modern Authentication. This software helps you to export G Suite to PST format as well.

Process to Transfer from Google Workspace to Microsoft 365

1. Install and run the Cigati Google Workspace to Office 365 Migration Tool.
   
   
2. Authenticate the source Google Workspace tenant (OAuth 2.0 or domain-wide delegation).
   
   
3. Select the users or mailboxes going into the current batch.
   
   
4. Authenticate the destination Microsoft 365 tenant.
   
   
5. Enter the login credentials via Modern Auth or Client ID/Secret ID.
   
   
6. Map each source user to its destination mailbox.
   
   
7. Apply filters: date range, item type, duplicate handling, resume-on-failure.
   
   
8. Run the batch and review the completion report before starting the next one.
   
   

Troubleshoot Problems That Come Up Mid-Migration

• Migration stalls partway through: Usually a dropped connection or an expired OAuth token. Resume-capable tools pick the job back up from the last completed item; tools without that capability force a restart, which on a large mailbox can mean re-processing hours of work.
• Duplicate messages appear after a second run: This almost always traces back to re-running a batch without duplicate detection enabled. Turn it on before any repeat pass over the same mailboxes.
• Folders or labels look wrong on the Outlook side: Confirm the label-to-folder mapping rules were configured before the batch ran, and give the destination mailbox time to finish indexing before assuming content is actually missing.
• Calendar events land without recurrence or lose external attendees: This points to a migration method that flattened calendar data into plain text instead of reading it as structured events. It typically requires a re-run through a tool that explicitly supports recurring series and attendee lists.
• Files land in SharePoint with the wrong owner or open permissions: Check whether the tool supports ownership mapping – attributing each file to the corresponding destination user – rather than defaulting everything to the migrating admin account.

Wrapping Up

A Google Workspace to Microsoft 365 migration is really five or six smaller migrations happening under one project name: mail, contacts, calendar, Drive, tasks, and groups, each with its own data model and its own platform limits. Microsoft’s built-in G Suite migration tool handles straightforward, mail-only moves well. Anything involving Drive content, calendar recurrence, permission mapping, or more than a couple hundred mailboxes tends to need software like Cigati Google Workspace to Office 365 Migration Tool that throttles against both platforms’ API ceilings, and is verified against a checklist before the old tenant is ever switched off.

Related Post