Migrate Google Workspace to Outlook: 2026 Admin Guide

The first question to settle is which Outlook you actually mean, because the answer changes the entire migration plan. Outlook.com is Microsoft's free consumer service: signup-grade mail, no admin console, IMAP works with app passwords. Microsoft 365 is the tenant-managed paid service that hosts Outlook desktop and Outlook on the web for business: admin console, compliance tools, custom domain, migration batches, the whole stack. People say "we're moving to Outlook" and mean either one. This guide covers both but spends most of its words on the M365 path because that's where the operational complexity lives.

First: Outlook.com or Microsoft 365?#

Decide before anything else. The differences are not cosmetic.

Outlook.com (consumer)

• Free, signup at outlook.com.
• Single user, no admin console.
• Custom domain support requires Microsoft 365 Personal/Family ($9.99/month-ish) which is technically still consumer-grade.
• IMAP with app passwords works.
• No calendar/contacts migration help — manual export/import.
• Best for a single individual moving a personal Workspace mailbox.

Microsoft 365 (business)

• Paid per-user license (Business Basic to Enterprise E5).
• Admin console, compliance, eDiscovery, conditional access.
• Custom domain via tenant verification.
• IMAP migration batches in Exchange admin center.
• Calendar/contacts as separate workstreams.
• Best for organisations with multiple users.

The rest of this guide assumes Microsoft 365 unless otherwise noted. For the consumer path, treat it as a single-user IMAP migration with app passwords on both sides and skip the tenant prep sections.

Pre-flight on the M365 destination#

Get the destination tenant clean before pointing anything at the source.

• Verify the destination domain. If you're keeping your primary domain, add it as an accepted domain in Exchange admin center and complete the TXT verification. Don't change MX yet.
• Provision all destination users. Use the same primary email address as the Workspace source. PowerShell: New-Mailbox or use the M365 admin center bulk import. Mismatched addresses cause migration batches to skip mailboxes silently.
• Set licenses. M365 Business Standard or Business Premium are the usual choices. Pool the licenses; assign as users get provisioned. Confirm storage per mailbox (50 GB on Business Standard, 100 GB on E3+) is enough for source mailbox sizes.
• Configure aliases. Every Workspace alias must exist on the matching M365 user. Export from Workspace admin → Users → secondary email addresses, import as proxyAddresses on M365 users.
• Disable spam filtering for migration source IPs. In Exchange admin → mail flow → rules, create a transport rule that bypasses spam classification for messages from the migration tool's source IP range.
• Decide on shared mailboxes upfront. Workspace has no native shared mailbox concept — what looks like a shared inbox is typically a Group with collaborative inbox. Decide whether each becomes an M365 shared mailbox (no license) or a real user account.

Pre-flight on the Workspace source#

Source-side prep is identical to any other Workspace migration.

1. Enable IMAP for all users. In Workspace admin → Apps → Google Workspace → Gmail → User settings → IMAP access. Set to "Enable IMAP access for all users".
2. Generate per-user app passwords or configure OAuth. For OAuth, register Microsoft as a trusted OAuth client in Workspace admin (Security → API controls → Domain-wide delegation). Add the M365 migration service principal with https://mail.google.com/ scope. For app password, each user generates one at myaccount.google.com → Security → App passwords.
3. Increase IMAP bandwidth allowance. Workspace's default IMAP bandwidth limit is roughly 2.5 GB per day per user. For large mailboxes, you'll need to request a temporary increase via Workspace support, or accept that the migration takes multiple days per user.
4. Audit 2-Step Verification policies. If your Workspace has enforced 2SV with security keys only, app passwords are blocked and OAuth is your only option. Confirm OAuth works end-to-end before kicking off the migration.

Folder mapping#

Gmail and Outlook map mostly cleanly, with the same caveats as any label-to-folder translation.

Workspace source	Outlook destination	Notes
Inbox label	Inbox	Direct map
Sent label	Sent Items	Sent flag preserved
Drafts label	Drafts	Migrated but rarely useful
Trash	Deleted Items	30-day auto-purge
Spam	Junk Email	Outlook re-classifies on its own filter
Custom labels	Folders with same name	Labels become folders
Nested labels	Nested folders	Forward-slash delimiter both sides
Starred	Flagged (red flag)	Direct flag map
Important	(lost)	Gmail importance markers don't translate
Categories (Outlook only)	n/a	Source side has labels, not categories
Calendar	Outlook Calendar	Separate workstream — not via mail batch
Contacts	Outlook People	Separate workstream — not via mail batch
Groups (collaborative inbox)	Shared mailbox	Migrate as shared mailbox, not group

The duplication problem: a Gmail message with three labels becomes three copies in Outlook, one per folder. M365 migration batches default to creating duplicates. To prevent this, pre-process Gmail to remove redundant labels, or use a desktop tool with primary-label-only mode.

Running the migration via Exchange admin center#

1. Open Exchange admin center migration page

   M365 admin → Exchange admin center → Migration → Add migration batch → Migrate to Exchange Online → IMAP migration. Choose Gmail as the source (or "Other IMAP server" with imap.gmail.com if Gmail isn't listed). Enter source endpoint details: server imap.gmail.com, port 993, encryption SSL/TLS.

2. Build the migration endpoint and test

   The endpoint is a saved configuration for the source server. Create it with a test admin account first to confirm connectivity. If Workspace shows AUTHENTICATIONFAILED during the endpoint test, the cause is always one of: 2SV blocking app password, OAuth domain-wide delegation missing, IMAP disabled in Workspace admin. Fix and retest.

3. Upload the migration CSV

   Build a CSV with columns: EmailAddress, UserName, Password. Source emails are the Workspace addresses; usernames are typically the same; passwords are per-user app passwords (or skip the password column entirely for OAuth). Upload to the migration batch.

4. Run a pilot batch of 3–5 users

   Pick three users from different teams. Add them to a pilot migration batch with start date "now". Watch the per-user status. Time the pilot — this gives you your throughput baseline. Validate destination mailboxes: folder structure, attachments, flags, message counts.

5. Stage production waves of 25–50 users

   Each wave is a separate migration batch. Workspace's outbound IMAP cap of ~2.5 GB per user per day will be the primary throughput bottleneck. Stagger waves 12–24 hours apart so source-side bandwidth resets.

6. Monitor errors and re-run gaps

   Migration batch errors show per-user. Common errors: AUTHENTICATIONFAILED (re-auth or new app password), Quota exceeded (Workspace daily bandwidth cap hit — wait 24 hours), Too many simultaneous connections (Workspace caps roughly 15 IMAP connections per user — reduce concurrency). M365 supports incremental sync; the batch will continue picking up new source mail until you explicitly complete it.

7. Reconcile and cutover

   Once all batches show "Synced", compare folder counts source vs destination. Re-run any with >1% discrepancy. Schedule MX cutover for a low-traffic window. Update DNS to point MX at M365 (yourdomain-com.mail.protection.outlook.com). Run one more delta sync 24 hours post-cutover.

Errors you'll see in production#

• AUTHENTICATIONFAILED Invalid credentials on Workspace source — app password mismatched or 2SV blocking. Regenerate or check OAuth delegation.
• OAuth2 token expired — Microsoft service principal's token refresh failed. Re-auth migration admin.
• Quota exceeded — Workspace daily IMAP bandwidth cap. Wait 24 hours, request cap increase.
• Message too large for destination — M365 default is 35 MB inbound, Workspace caps outbound at 25 MB. Rare unless Workspace admin raised the limit.
• Too many simultaneous connections — Workspace user cap is roughly 15 concurrent IMAP connections. Reduce wave concurrency.
• Folder UTF-7 conversion error — non-ASCII label names. Rename or accept mangled destination folder names.
• ServerBusyException on M365 — Microsoft destination throttling. Reduce concurrency, do not retry harder.

What doesn't move#

• Google Calendar. Export ICS from calendar.google.com → import to Outlook Calendar. Resource calendars need manual recreation in M365.
• Google Contacts. Export CSV from contacts.google.com → import to Outlook People.
• Google Drive. Completely separate. Plan as a Drive-to-OneDrive sync workstream.
• Gmail filters. Outlook's rules engine is different. Document top 10 filters per user, rebuild manually.
• Mailbox delegation. Workspace's "give Alice my mail access" maps to M365's Send-On-Behalf-Of and Full Access, but the migration doesn't carry the permission. Re-grant per user post-cutover.
• Google Groups. Static membership migrates if you provision distribution groups in M365 with the same membership. Dynamic groups need to be recreated.
• Vault retention policies. M365 has Purview retention, but the policies don't transfer. Rebuild from your Vault retention rules document.

Comparing migration paths#

Three real paths exist for Workspace to Outlook:

1. M365 Exchange admin center IMAP migration (this guide). Native, free, supports OAuth, handles incremental sync. Best for 1–500 users.
2. A SaaS migration service. Hand both credentials to a hosted vendor. Fast, expensive, requires trust.
3. A desktop IMAP migration tool. Local, no admin impersonation, no calendar/contacts. Best for one-off cleanup, departed users, or PST-bound archives.

For broader context, the Microsoft 365 migration guide covers tenant prep and licensing. The reverse direction is covered in Outlook to Workspace migration. For the tenant-equivalent path, Workspace to Microsoft 365 specifically is the operational reference. For a single-user personal Workspace move rather than a tenant, Gmail to Outlook is the simpler walkthrough. And the Google Workspace migration guide covers source-side prep regardless of destination.

After cutover#

• Days 1–3. Final delta migration batch runs. Monitor inbound mail in M365 to confirm DNS propagation. Watch for users still typing the old reply-to.
• Days 4–10. Rebuild rules, signatures, mailbox delegation. Outlook's rules engine takes ~30 minutes per power user to rebuild from a Gmail filter export.
• Days 11–20. Decommission Workspace licenses for migrated users. Keep one admin license active for forensics. Disable spam filtering on the now-empty Workspace tenant.
• Days 21–30. Final reconciliation report. Archive migration batch logs for audit. Schedule training sessions for users struggling with Outlook's folder model after years of Gmail labels.
• Day 60+. Decommission Workspace tenant or convert to archive-only. Cancel subscription.

The non-technical risk is the bigger one. Users who lived in Gmail for 10 years will struggle with Outlook's lack of conversation view (Outlook now has conversation threading but it's optional and most users turn it off), the folder-not-label model, and Calendar's invite UI. Budget two weeks of hand-holding past the official cutover date, and consider a structured training program for the largest teams.