Migrate Exchange Online to Gmail: The Engineer's Playbook

Exchange Online and Microsoft 365 are the same product from a migration tool's perspective: a cloud Exchange mailbox accessed via EWS or Graph, authenticated through Entra ID. So when you read "migrate Exchange Online to Gmail," you can mentally substitute "Microsoft 365 to Gmail" — the steps, the throttle limits, and the gotchas are identical. This guide walks through Google's Data Migration Service (DMS) approach, the OAuth consent flow that trips up most first-time migrators, and the post-cutover validation that catches the 0.5 percent of messages that always seem to go missing.

Exchange Online vs Microsoft 365: the same product#

If you are coming at this fresh: Microsoft 365 is the suite (Word, Excel, Teams, mailboxes). Exchange Online is the mailbox component. The licence that matters for this migration is the one that includes an Exchange Online plan — typically Business Standard, Business Premium, E3, or E5. From the source mailbox's perspective, the API surface is the same.

Microsoft also still uses "Office 365" interchangeably in some places. The branded name has changed, the underlying service has not. Anything in our Office 365 to Gmail walkthrough applies here unchanged.

Pre-migration audit#

Connect to Exchange Online PowerShell:

Connect-ExchangeOnline -UserPrincipalName admin@yourtenant.onmicrosoft.com

Then pull a mailbox inventory:

Get-Mailbox -ResultSize Unlimited |
  Select-Object UserPrincipalName, RecipientTypeDetails,
    @{n='SizeGB';e={(Get-MailboxStatistics $_).TotalItemSize.Value.ToBytes()/1GB}},
    @{n='Items';e={(Get-MailboxStatistics $_).ItemCount}},
    LastLogonTime |
  Sort-Object SizeGB -Descending |
  Export-Csv mailbox-audit.csv -NoTypeInformation

The CSV is your project tracker. Sort by size. The top 5 percent of mailboxes drive most of your timeline. Pull these out for parallel migration alongside the bulk batch.

Also collect:

• Distribution group membership: Get-DistributionGroup | Get-DistributionGroupMember
• Shared mailboxes: Get-Mailbox -RecipientTypeDetails SharedMailbox
• Resource mailboxes (rooms, equipment) — recreate in Google Calendar as resources, not mailboxes
• Server-side rules: per user, Get-InboxRule and document the ones that matter
• Transport rules at the org level: Get-TransportRule (these become Gmail compliance rules)

Google Workspace preparation#

Provision your destination domain in the Google Admin Console:

1. Verify domain ownership via TXT record. This must complete before any migration starts.
2. Create users matching every Exchange Online identity you intend to migrate. Match the primary SMTP address exactly — the Data Migration Service maps source-to-destination by email address.
3. Assign appropriate Workspace licences (Business Standard or above gets you the full feature set; Business Starter has a 30 GB cap that may exclude your large mailboxes).
4. Pre-configure user-facing labels, filters, and groups so users land in a working environment.

Do not change MX records yet. Google should be invisible to end users until cutover.

Setting up the Data Migration Service#

In the Google Admin Console, navigate to Account → Data Migration → Set up. Choose:

• Migration source: Microsoft Exchange
• Connection protocol: EWS (auto-detected when you point at Microsoft 365)
• Source authentication: OAuth (recommended; the alternative is per-user app passwords)

When you click through, Google redirects you to Microsoft for OAuth consent. Sign in as a Global Admin of the source tenant. Microsoft will display the requested scopes — typically Mail.ReadWrite, Mail.Send, and User.Read.All at the application level. Click consent. This creates an Entra ID app registration that the DMS uses for the duration of the migration.

After consent, Google asks for the source endpoint. For Exchange Online this is always https://outlook.office365.com/EWS/Exchange.asmx. Do not change this even if you have hybrid setups — DMS is talking to the cloud side specifically.

Pilot and batch#

1. Run a three-user pilot

   Pick a small mailbox (under 2 GB), a medium one (5 to 10 GB), and a large one (20 GB or more). Add them via Data Migration → Add User, mapping source UPN to destination Gmail address. Start the migration.

2. Validate the pilot

   Once complete, log in as each pilot user. Check label counts versus source folder counts (Gmail uses labels, not folders, but DMS preserves the hierarchy with slashes). Check total item count, sent items, and any items with attachments. Confirm starred status and read/unread state.

3. Scale in batches of 50 to 100

   DMS handles concurrent users well. Microsoft throttling is your real ceiling. If you see OAuth2 token expired or repeated 429 Too Many Requests, reduce batch size.

4. Export calendars and contacts in parallel

   Per user, export the calendar to ICS via OWA and import into Google Calendar. Export contacts to CSV and import. This runs alongside the mail migration and can be scripted on the Exchange Online side with Graph API.

5. Run delta migrations

   DMS supports delta runs. After the initial full sync, re-run the migration 24 hours before cutover and again 1 hour after MX switch.

OAuth and authentication details#

Google's DMS uses a server-to-server OAuth flow against Microsoft's /common/oauth2/v2.0/token endpoint. The app registration created during consent will appear in Entra ID under Enterprise Applications → All Applications with a name like "Google Workspace Data Migration Service." You can audit its activity in the Entra sign-in logs.

After the migration is complete, revoke the consent:

1. Entra ID → Enterprise Applications → find the DMS app
2. Properties → Delete (or set Enabled = No)

This closes the access path. Leaving the consent in place is not catastrophic, but principle of least privilege says clean it up.

If you previously enforced Conditional Access policies that block legacy auth, you may need a CA exclusion for the DMS service principal during the migration window. The simplest path: scope the exclusion to a specific named app and remove it when DMS finishes.

Cutover sequence#

T-7 days: send first user comms.

T-72 hours: drop MX TTL to 300 seconds.

T-48 hours: stop creating new mailboxes in Exchange Online. Any new hires get Workspace accounts directly.

T-24 hours: run a delta DMS pass.

T-2 hours: notify users mail will be unavailable for roughly 30 minutes during the MX switch.

T-0: change MX records to Google's published values. Verify globally via dig MX yourdomain.com @8.8.8.8 @1.1.1.1.

T+30 minutes: send a test from an external Gmail account. It should land in Workspace.

T+90 minutes: run the final DMS delta to catch in-flight messages.

T+24 hours: validate SPF, DKIM, DMARC alignment via Google Postmaster Tools.

DNS records#

Publish before cutover (do not wait):

• SPF: v=spf1 include:_spf.google.com ~all
• DKIM: enable in Admin Console → Apps → Google Workspace → Gmail → Authenticate email. Publish the generated google._domainkey TXT record.
• DMARC: start at v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com and tighten to p=quarantine after 30 days of clean reports.

Only change the MX record at cutover.

What does not move#

Be honest with users about the metadata DMS does not preserve:

• Server-side Inbox rules: gone. Document and recreate as Gmail filters.
• Outlook signatures: stored in the mailbox under IPM.Note.Signatures — IMAP and EWS migrations do not move them. Have users recreate or use a centralised signature tool like Wisestamp post-cutover.
• Conversation Action Settings: invisible to DMS.
• Recoverable Items / Litigation Hold contents: not migrated. If you have legal hold obligations, keep the Exchange Online tenant alive until the hold expires, or export to PST first.
• Shared mailbox permissions: shared mailbox content moves if you migrate it as a user, but the access grants do not. Re-grant in Workspace via group delegation.

Where Mailbox Taxi fits#

Google's DMS is purpose-built for full-mailbox transfers from Microsoft 365. It does the bulk job well. It is less useful for:

• Filtered migrations (specific folders, date ranges, label scopes)
• One-off re-runs for individuals after a failed migration
• Departing-employee mailboxes you want to capture to a local archive without uploading credentials to a third party
• Hybrid scenarios where you want to keep some users on Microsoft 365 indefinitely while others are moved

Mailbox Taxi runs locally, speaks IMAP to both sides, and gives you per-folder and per-date-range control. It is the right tool for the messy 5 percent of any DMS-led migration that needs surgical handling.

If you are also evaluating whether some teams should stay on or move toward Microsoft 365 instead of Gmail, our Exchange to Office 365 walkthrough covers the inverse case.

Common errors and fixes#

OAuth2 token expired — the DMS service principal token timed out, usually after a long-running batch. DMS auto-refreshes, but if you see this repeatedly, reduce concurrent users or re-consent the app.

429 Too Many Requests — Microsoft EWS throttling. Reduce batch size, schedule outside business hours.

Folder UTF-7 conversion error — non-ASCII characters in source folder names. Rename them via OWA before migration.

Message too large for destination — Gmail's per-message limit is 25 MB for sending but it accepts up to 50 MB on receive via DMS. Messages over 50 MB will fail; export them separately.

AUTHENTICATIONFAILED — consent has been revoked or the admin who consented has had their role removed. Re-consent with a current Global Admin.

For a broader error catalogue across providers, the complete email migration guide is the right reference.

Post-cutover validation#

Three checks in week one:

1. Item count delta per user: compare Gmail's per-label counts against your Exchange Online baseline. Variance under 1 percent is normal — DMS dedupes some items that Exchange counted as separate (calendar items inside the mail folder, for example).
2. DNS alignment: Postmaster Tools should show SPF and DKIM passing within 72 hours.
3. End-user smoke tests: pick five random users and walk through their daily workflow (search, compose, reply, forward, mobile access).

After 30 days of stable Workspace operation, you can begin Exchange Online decommissioning. Microsoft retains licence-free mailboxes for 30 days before purging, so confirm everything is in Gmail before you release licences.

For the higher-level program view (especially if you are running multiple tenant moves in parallel), the pillar Office 365 migration guide and the Google Workspace migration guide cover the source and destination sides respectively.