Migrate Outlook to Google Workspace: 2026 Admin Guide

The board signed off on Google Workspace. You have 60 days, a Microsoft 365 tenant full of Outlook mailboxes, an org chart with 240 names, and the unhelpful expectation that this is a "lift and shift". It isn't. Three things make Outlook-to-Workspace genuinely hard: Microsoft's throttling on outbound IMAP, Google's per-user daily ingestion ceiling, and the fact that calendar resources, delegate permissions, and shared mailboxes are first-class objects in Microsoft 365 but second-class concepts in Workspace. This guide is the operational plan you actually run, not the brochure version.

Decide your migration path first#

You have four real paths from Outlook into Google Workspace. Pick before you provision anything.

Path 1: Google Data Migration Service (DMS). Free, runs from the Workspace admin console, supports Microsoft 365 / Exchange Online sources via OAuth, handles mail + calendar + contacts in separate jobs. Best for 1–500 users, no on-premises PSTs, no on-premises Exchange. This is the path the rest of this guide focuses on because it's right for most teams.

Path 2: Google Workspace Migration for Microsoft Exchange (GWMME). Windows-only desktop tool, installs on a beefy migration server, talks MAPI/EWS to the source and Google APIs to the destination. Higher throughput than DMS, supports PSTs, but you need a Windows host and you handle batching yourself. Best for 500+ users, large PST archives, or hybrid Exchange environments.

Path 3: Native IMAP migration. Walk each mailbox as IMAP source → Workspace IMAP destination using a third-party tool. Simpler than GWMME, doesn't need admin impersonation, but doesn't move calendar or contacts. Best for small migrations (under 50 users) or where you want full local control.

Path 4: SaaS migration service. Hand both credentials to a hosted vendor. Fast to set up, expensive, and requires you to trust a third party with mailbox-level access to both sides.

For everything else assume DMS unless we say otherwise.

What to prepare on the Workspace side#

Before you touch the source, get the destination in order. A clean target dramatically reduces failed migrations.

• Provision all user accounts. Create the destination Workspace users with the same primary email addresses. If you're keeping the domain, you'll need to verify it on Workspace before MX cutover.
• Set licensing. Workspace Business Standard gives each user 2 TB pooled storage. Business Plus is 5 TB pooled. If you're migrating a heavy archive user with 50 GB of mail, confirm the pooled allocation handles it.
• Configure aliases. Outlook users often have 3–5 SMTP aliases each. Map every alias to its primary destination user in Workspace before migration. DMS uses the primary address for matching; orphan aliases are silently dropped.
• Turn off Google's spam quarantine during ingestion. Set an inbound gateway rule that bypasses spam filtering on messages from the migration IPs. Otherwise you'll find 5–8% of legitimate-looking historical mail sent to quarantine.
• Pre-stage groups and shared mailboxes. Workspace's equivalent of an Exchange shared mailbox is a Google Group with collaborative inbox enabled, or a dedicated user account. Decide which pattern you want before migrating.

Source-side preparation in Microsoft 365#

On the Outlook / M365 side, you need three things in place before you point DMS at the tenant:

1. A global admin account with mailbox impersonation rights. DMS uses this account to authenticate and read all source mailboxes. You can use a delegated migration admin instead of full global admin, but the role needs ApplicationImpersonation (Exchange Online) and read permission on every mailbox in scope.
2. App registration in Entra ID (formerly Azure AD). Register an enterprise application for DMS with permissions EWS.AccessAsUser.All or full_access_as_app, then grant admin consent. Google's DMS docs publish the exact app manifest; copy it as-is and don't drift from the template.
3. IMAP and EWS enabled tenant-wide. Many security-hardened tenants disable both. Confirm via PowerShell: Get-CASMailbox | Where-Object {$_.ImapEnabled -eq $false} will list mailboxes with IMAP off. Re-enable for the duration of the migration.

If you're on hybrid Exchange (some mailboxes on-prem, some in Exchange Online), DMS only sees the Exchange Online ones. On-prem mailboxes need to be migrated to Exchange Online first or migrated separately via IMAP from the on-prem CAS server.

Folder and item mapping#

Outlook and Gmail's folder models don't agree. Here's how items translate:

Outlook concept	Google Workspace equivalent	Notes
Folder	Label	Gmail labels behave like folders for migrated mail
Subfolder	Nested label	Nested labels work, depth limited to ~10 levels
Inbox	Inbox	Direct, no issue
Sent Items	Sent	Sent items keep their \Sent flag
Deleted Items	Trash	Items in Deleted get migrated to Trash; auto-purge in 30 days
Junk Email	Spam	Migrated but Workspace re-evaluates with its own filter
Categories (coloured)	Labels (with colour)	Outlook colour categories convert to coloured labels
Flags / follow-up	Starred	Outlook flags map roughly to Gmail stars
Calendar events	Calendar events	Migrated via DMS calendar job, not mail job
Contacts	Contacts	Migrated via DMS contacts job, not mail job
Tasks	(lost)	No native migration; export to ICS and re-import to Tasks
Notes	(lost)	Outlook Notes have no Workspace equivalent

Custom folders become custom labels with the same name. Deep nesting works fine. The two real losses are Tasks and Notes — there is no automated path for either.

The actual migration#

1. Run a pilot of 3–5 real mailboxes

   Pick three real users from different teams — ideally one heavy mail user, one light user, one with calendar resources. Run DMS end-to-end for those three. Validate: mail counts match within 1%, calendar events appear in the right calendars, contacts are searchable. Time the pilot — you'll use that to estimate the full run.

2. Build migration waves of 25–50 users

   DMS can run multiple users in parallel but the per-tenant ingestion cap is roughly 5 GB per user per day across the whole tenant. Sending 200 users at once means each gets throttled. Stage 25–50 at a time, ideally grouped by department so cutover support is easier.

3. Run the mail job first, then calendar, then contacts

   DMS runs each as a separate job. Mail is the largest and slowest, so start it first. Once mail is done for a wave, kick off calendar (typically 30–90 minutes per user) then contacts (under 10 minutes per user). Don't run all three concurrently for the same user — they share OAuth scopes and you'll hit token contention.

4. Monitor for token expiry and re-auth as needed

   OAuth tokens have a 60–90 minute lifetime. DMS refreshes automatically in most cases, but a tenant-wide conditional access policy change can revoke tokens mid-migration. Watch for OAuth2 token expired and AUTHENTICATIONFAILED in the DMS error report; re-auth and resume affected users individually.

5. Reconcile counts and re-run gaps

   For each migrated user, compare source mailbox folder counts (PowerShell Get-MailboxFolderStatistics) against destination label counts (Gmail API messages.list per label). Discrepancies above 0.5% need a re-run of the affected folders. DMS supports incremental delta runs — just relaunch and it picks up only new messages.

6. Schedule MX cutover

   Once mail counts reconcile for the whole organisation, schedule MX cutover for a low-traffic window (Friday evening or Sunday morning are standard). After MX flips, run a final 24-hour delta DMS pass to catch anything that arrived during cutover. Communicate the cutover window to users at least 5 days in advance.

Errors you'll actually see#

• ApplicationImpersonation role missing — your migration admin doesn't have impersonation rights. Grant via PowerShell: New-ManagementRoleAssignment -Role ApplicationImpersonation -User migration.admin.
• ServerBusyException — Microsoft outbound throttling. Reduce concurrent users by half.
• Item not found during incremental run — a message was deleted from source between full and delta runs. Safe to ignore but log for audit.
• Quota exceeded on destination user — Workspace user has hit their pooled storage cap. Either upgrade license tier or skip large attachments via a DMS attachment-size limit.
• Folder UTF-7 conversion error — non-ASCII folder names in Outlook. Rename or accept that a small number of folders may appear with mangled names in Workspace; rename post-migration.

What doesn't move#

Set expectations with stakeholders before, not during:

• Outlook signatures. Stored client-side, not in the mailbox. Users must rebuild in Gmail.
• Outlook rules. DMS does not migrate Inbox rules. Document the top 5 rules per user with a PowerShell export, then have users rebuild in Gmail.
• Mailbox delegation. Outlook's "give Alice Send-On-Behalf rights" doesn't map cleanly. Workspace uses Gmail delegation which requires re-granting per user.
• Public folders. No Workspace equivalent. Migrate to Shared Drives + Google Groups.
• Online archives. Microsoft 365's in-place archive (the second mailbox attached to a user) needs a separate DMS job pointed at the archive endpoint.
• OneDrive attachments referenced inline. Messages with OneDrive sharing links migrate, but the links keep pointing to OneDrive. Plan a OneDrive-to-Drive migration as a separate workstream.

Why a desktop tool is still useful here#

Even on a DMS-led migration, a desktop IMAP tool like Mailbox Taxi pays off in three scenarios:

1. PST archives on user laptops. DMS can't see them; GWMME requires Windows infrastructure. A laptop-local desktop tool can read the PST and push directly to the destination Workspace user.
2. One-off departed-user migrations. A single former employee's mailbox going to their replacement's archive — running DMS for one mailbox is overkill.
3. Pilot validation. Running a quick IMAP-only test alongside DMS confirms the destination accepts mail before you commit a full tenant batch.

For broader context on planning a Workspace migration, see the Google Workspace migration guide which covers tenant prep, licensing, and the people-side change management. The specific Microsoft 365 source path is detailed in migrating Microsoft 365 to Google Workspace. If you're going the other direction, the Workspace to Outlook migration guide covers the reverse path. For a single-mailbox personal flow (no tenant), the Outlook to Gmail migration guide is the simpler walkthrough. The complete email migration guide is the higher-level playbook that ties all of these together.

Post-migration: the next 30 days#

• Week 1. Daily delta DMS runs for any wave still active. Monitor Gmail's "Mail delivery problem" feedback for misrouted forwarders.
• Week 2. Rebuild user signatures and inbox rules. Schedule training sessions for power users (calendar invites, delegated access, filters).
• Week 3. Decommission Exchange Online licenses for migrated users (keep one admin license active for forensics). Turn off the source tenant's spam filtering since no real mail arrives there anymore.
• Week 4. Run a final reconciliation report comparing source and destination message counts. Archive the DMS job logs for compliance audit purposes.
• Day 60+. Plan source tenant decommission. Keep the tenant alive for at least 90 days post-cutover to handle stragglers (auto-renewing subscriptions, forgotten 2FA backups).

The non-technical risk is bigger than the technical one. Users who lived in Outlook for 10 years will resist Gmail's threaded conversation view, will hate that labels aren't folders, will fight Calendar's invite UI. Budget two weeks of "your migration is over but your support tickets aren't" before the project officially closes.