Migrate Microsoft 365 to Google Workspace: DMS Path 2026

Microsoft 365 to Google Workspace is one of the most common tenant-to-tenant migrations of 2026, and also one of the most over-promised. Vendors sell it as a one-click move. In practice you're coordinating two distinct identity providers, two distinct mail authorisation models, two storage backends with incompatible folder semantics, and an organisation full of users who will not enjoy the change. Google's Data Migration Service (DMS) is the right tool for most teams under 500 users, and the rest of this guide is the operational plan you actually run.

When DMS is the right tool#

DMS handles the 80% case. It's the right choice if:

• Your source is Microsoft 365 / Exchange Online (not on-prem Exchange Server). DMS speaks EWS/OAuth and needs the tenant-managed endpoints.
• You're moving 1–500 user mailboxes. Above that, plan multiple DMS instances or look at a partner-led GWMME deployment.
• You can grant a global admin or delegated migration admin OAuth access to the source tenant for the duration of the project.
• You don't have meaningful local PST archives. DMS reads only what's in the mailbox; PSTs on user laptops are invisible.
• Your security team is OK with an Entra ID enterprise application that has mailbox-impersonation rights for the migration window.

If any of those fail (on-prem Exchange, 500+ users, lots of PSTs), look at Google Workspace Migration for Microsoft Exchange (GWMME) or a hybrid approach instead. Most teams I see start with DMS and either finish there or shift one or two outlier mailboxes to a desktop IMAP tool for cleanup.

Pre-flight on the destination Workspace tenant#

Get the destination right first. Reworking a half-migrated tenant is more expensive than spending a day on prep.

• Verify the destination domain. If you're keeping your primary domain, add it as a secondary domain in Workspace and complete the TXT verification. MX stays pointed at Microsoft during migration; the verification just proves you own the domain.
• Provision all destination users. Use the same primary email address as the M365 source. Workspace user alice@company.com needs to exist before DMS will migrate alice@company.com's mail. Use Google Cloud Directory Sync (GCDS) or a CSV import for bulk creation.
• Set licenses. Workspace Business Standard (2 TB pooled), Business Plus (5 TB pooled), or Enterprise Standard for compliance features. Add up source mailbox sizes; if total exceeds pooled allocation, upgrade tier or plan for archive-only users to migrate to Workspace Archive Mailboxes (Vault).
• Configure aliases. Every M365 alias must exist on the matching Workspace user. Run Get-Mailbox | Select PrimarySmtpAddress, EmailAddresses in Exchange PowerShell to export the alias list, then bulk-import to Workspace.
• Disable spam filtering on inbound migration paths. Create a content compliance rule in Workspace admin (Apps → Gmail → Routing) that bypasses spam classification for messages with the DMS source IP range as the originating gateway.
• Pre-stage Google Groups for shared mailboxes. Don't migrate M365 shared mailboxes as regular users unless you intend to keep them that way. Decide upfront: collaborative inbox group or licensed user.

Pre-flight on the M365 source tenant#

The source side is where DMS most often fails to authenticate. Get this right and the rest is just patience.

1. Confirm Exchange Online is the actual source. PowerShell: Get-OrganizationConfig | Select Name, IsHybrid. If IsHybrid is true, on-prem Exchange may have some mailboxes; those need to be migrated to Exchange Online first or migrated separately.
2. Enable IMAP and EWS tenant-wide for the migration window. Hardened tenants disable both. PowerShell: Set-CASMailbox -Identity user@domain.com -ImapEnabled $true -EwsEnabled $true. DMS uses EWS; the IMAP toggle is for fallback and incremental delta runs.
3. Register an Entra ID application for DMS. In the Entra ID portal, create a new app registration. Add API permissions: Office 365 Exchange Online → full_access_as_app. Grant admin consent. Note the application (client) ID and tenant ID — DMS asks for both.
4. Grant ApplicationImpersonation to the migration service account. PowerShell: New-ManagementRoleAssignment -Role ApplicationImpersonation -User dms.svc@yourdomain.com. This is the role DMS uses to read every source mailbox via the registered app.
5. Audit conditional access policies. If your tenant has a conditional access policy blocking legacy auth or unknown locations, the DMS app may get blocked silently. Create an exclusion for the migration service account and the registered app for the migration window.

A common failure: the org has a security policy that auto-revokes service principal credentials weekly. DMS runs for 5+ days. Coordinate with the identity team to extend the lifetime, or schedule the migration into shorter chunks.

Folder mapping reality check#

M365 and Gmail map cleanly for most folders, awkwardly for some:

M365 source	Workspace destination	Notes
Inbox	Inbox	Clean direct map
Sent Items	Sent	\Sent flag preserved
Drafts	Drafts	Migrated but rarely useful — drafts are stale
Deleted Items	Trash	30-day auto-purge on Workspace side
Junk Email	Spam	Workspace re-classifies on its own filter
Custom folders	Labels with the same name	Nested folders → nested labels
Archive (in-place archive mailbox)	Migrated as separate DMS job pointed at archive	Don't merge with primary
Categories (Outlook colour)	Coloured labels	Colour mapping is approximate
Calendar	Primary Calendar	Recurrence patterns preserved, reminders best-effort
Resource calendars	Workspace Resources	Migrate separately, not via DMS
Contacts	Google Contacts	Personal contacts only; org directory is GCDS-managed

The two real friction points: in-place archive mailboxes (always a separate DMS job, don't forget) and resource calendars (rooms, equipment) which DMS won't migrate at all — provision those manually in Workspace Resources.

Running DMS step by step#

1. Configure DMS in the admin console

   Apps → Data Migration → Set up data migration. Choose Microsoft 365 as the source, mail as the type. Enter your source tenant ID, application client ID, and the email address of the impersonation service account. Click "Connect" and authenticate. If the connection test fails, the issue is always one of: missing impersonation role, missing app consent, blocked by conditional access. Fix and retry.

2. Run a 5-user pilot wave

   Pick five real users from different teams. Add them to a "pilot" DMS migration with start date "now" and end date "all time". Watch the per-user status in the console. Time the pilot from kickoff to "complete" — this gives you your throughput baseline. Validate destination mailboxes: counts, attachments, labels, calendar events.

3. Build waves of 25–50 users

   For the production run, group users by department. Each wave gets its own DMS migration object. Stagger waves by 12–24 hours so source-side throttling has time to reset. Don't run more than two concurrent waves — Microsoft's tenant-level EWS throttling caps at roughly 500 concurrent connections.

4. Run calendar and contacts jobs after mail

   DMS treats mail, calendar, and contacts as three separate migrations. Start mail first. Once a wave's mail jobs all show "complete", create a calendar DMS job for the same users, then a contacts job. Running all three concurrently against the same user fights for OAuth tokens.

5. Monitor for errors and re-run gaps

   The DMS console shows per-user status. Common errors and fixes: OAuth2 token expired → re-auth the migration service account; ServerBusyException → reduce wave concurrency; Quota exceeded → check Workspace pooled storage; Item not found → safe to ignore (deleted-on-source during run). DMS supports incremental delta runs — relaunch the job and it picks up only new messages since the last run.

6. Reconcile counts before MX cutover

   For each user, compare source mailbox folder counts with destination label counts. PowerShell on source: Get-MailboxFolderStatistics -Identity user@domain.com. Gmail API on destination: messages.list per label. Discrepancies above 1% need investigation. Re-run affected users via DMS delta before declaring the wave complete.

7. Switch MX records and run final delta

   Schedule MX cutover for a low-traffic window. Update DNS to point MX at Workspace SMTP gateways. Watch propagation (most resolvers honour TTL within an hour). Run one more DMS delta job 24 hours post-cutover to capture mail that arrived in M365 during DNS propagation. After that, M365 should receive zero new mail.

Errors you'll meet in production#

The DMS error report is your best friend. Familiarise yourself with these:

• AUTHENTICATIONFAILED on source — the service account credentials expired, conditional access blocked, or impersonation role got removed. Diagnose with PowerShell, not by retrying DMS.
• ServerBusyException — Microsoft outbound throttling. Reduce concurrent waves; do not retry harder.
• Quota exceeded — Workspace storage pool full. Add storage tier or skip large attachments.
• Message too large for destination — Gmail caps inbound at 50 MB. M365 caps at 25 MB by default, so this is rare but possible if your tenant raised the limit.
• OAuth2 token expired during long-running waves — your registered app's refresh token aged out, or conditional access revoked it. Re-auth the migration service account.
• Folder UTF-7 conversion error — non-ASCII folder names in Outlook. Rename pre-migration or accept mangled label names on the destination.

Comparing DMS against the alternatives#

Three paths cover almost all M365 to Workspace migrations:

1. DMS (this guide). Free, cloud-to-cloud, no infrastructure. Best for 1–500 users with no PSTs.
2. GWMME. Windows-based, runs on a migration server, higher throughput, supports PSTs. Best for 500+ users or PST-heavy archives.
3. Desktop IMAP migration tool. Local, no admin impersonation, no calendar/contacts. Best for one-off cleanup, departed users, or pilot validation alongside DMS.

For broader context on planning the destination side, see the Google Workspace migration guide. For the inverse direction, the Workspace to Microsoft 365 migration guide covers the reverse tenant move. For the source-side prep including tenant decommissioning, the Microsoft 365 migration guide is the operational reference. If you're migrating a small personal-style M365 mailbox rather than a tenant, the Microsoft 365 to Gmail walkthrough is the right shorter path. And for the broader tenant-vs-tenant playbook spanning identity and devices, the tenant-to-tenant migration guide ties the email move into the larger picture.

After cutover: the 30-day calendar#

• Days 1–3. Final delta DMS runs; monitor inbound mail volume on Workspace. Watch for users still typing the old domain into reply-to fields.
• Days 4–10. Rebuild Inbox rules, signatures, mailbox delegation. Document the top 5 rules per user from source PowerShell export, train users to rebuild.
• Days 11–20. Decommission Exchange Online licenses for migrated users. Keep one admin license active. Disable spam filtering on the now-quiet M365 tenant.
• Days 21–30. Final reconciliation report. Archive DMS logs for compliance. Audit Workspace ingestion to confirm no source-tenant addresses are still receiving real mail.
• Day 60+. Decommission the source tenant or convert to long-term archive mode. Cancel M365 subscription. Update vendor records.

The technical migration is the easier half. The harder half is helping 100+ users unlearn ten years of Outlook habits and accept Gmail's threaded conversation view, label-not-folder model, and Calendar's invite UI. Budget two weeks of hand-holding past the official cutover date.