How to Migrate Outlook to Gmail

Outlook-to-Gmail moves split into two camps the second you start them. Half your mailboxes are corporate Microsoft 365 accounts behind Modern Authentication, demanding an OAuth dance and a registered Entra ID app. The other half — usually the founders and the long-tenured marketing team — are personal @outlook.com accounts that still want an app password and a different IMAP hostname. Get the source flavor wrong and the batch fails before the first message moves. This guide handles both, and walks through the folder-to-label mapping that trips up users on day one.

What you need before you start#

The Outlook source side decides most of the work. The Gmail destination is consistent; the source isn't.

If your source is Microsoft 365 (corporate @yourcompany.com addresses, often called Office 365), you need:

• Global admin or Exchange admin rights on the source tenant.
• An Entra ID app registration with IMAP.AccessAsApp or delegated IMAP.AccessAsUser.All permissions, plus admin consent granted.
• The hostname outlook.office365.com on port 993 with TLS.
• A tenant where Modern Authentication is enabled for Exchange Online (default since 2022). If it isn't, you have a bigger problem than this migration.

If your source is Outlook.com (consumer @outlook.com, @hotmail.com, @live.com), you need:

• Owner access to each individual account.
• Two-step verification enabled, then an app password generated per account from account.microsoft.com, Security.
• The hostname imap-mail.outlook.com on port 993 with TLS.

If your source is on-premises Exchange, you need to enable IMAP on the Client Access role, open port 993 inbound from your migration tool's IP, and confirm the public certificate matches the FQDN. We won't go deep on on-prem here because the patterns match Microsoft 365 closely once IMAP is exposed.

On the Gmail (destination) side, regardless of source, you need:

• Google Workspace accounts provisioned for every user, with the right license tier.
• IMAP enabled in the Admin Console under Apps, Google Workspace, Gmail, End user access.
• App passwords per mailbox, or a service account with domain-wide delegation scoped to https://mail.google.com/. Service account is the only sensible option above 20 mailboxes.
• MX records ready to flip to aspmx.l.google.com and friends, with TTLs lowered 48 hours beforehand.

The migration in eight steps#

1. Decide what kind of Outlook you're migrating

   Inventory your source accounts before you touch any tooling. Run an export from your identity provider — Entra ID for Microsoft 365, or a manual list for Outlook.com — and tag every account as corporate, consumer, or on-prem. Three categories, three credential flows, and the migration tool needs to know which is which. Mixing them in a single batch is the most common cause of AUTHENTICATIONFAILED storms in the first hour.

2. Prepare the Gmail or Workspace destination

   Provision the destination accounts in the Google Admin Console. Confirm each user has a mailbox by sending a test message from a different Workspace account and watching it land. Lower the source MX TTL to 300 seconds 48 hours ahead of cutover so the eventual DNS change propagates fast. Verify the destination domain in Workspace and pre-stage MX records so you can switch them in one operation when the time comes.

3. Enable IMAP on the Outlook source

   For Microsoft 365 corporate, IMAP is on by default for mailboxes but the protocol may be disabled at the user level. Check with Get-CASMailbox <user> | Select-Object ImapEnabled in Exchange Online PowerShell, and re-enable any that are off. For Outlook.com, IMAP is always on but each user has to confirm it's not disabled in their personal settings. For on-prem, enable the IMAP4 service on the relevant role and confirm it's listening.

4. Choose your authentication path on the source

   For Microsoft 365 with Modern Authentication, register an Entra ID app with IMAP.AccessAsUser.All delegated permission, grant admin consent, and use the OAuth client credentials in your migration tool. Don't try to use Basic Authentication unless you absolutely have to — most tenants have it disabled, and re-enabling it triggers compliance alerts. For Outlook.com, generate an app password per account from the user's security page. There is no service account model for consumer Outlook.

5. Map folders to labels and run a pilot

   Migrate two pilot mailboxes — ideally one heavy user with a deep folder tree, and one light user with mostly inbox-and-archive. Confirm Outlook folders land as Gmail labels with the original hierarchy preserved by forward slashes (Projects/2024/Acme becomes a Projects/2024/Acme label in Gmail). Check the Sent Items folder maps to Gmail's Sent Mail, not a label called Sent Items. Check that the Junk Email folder doesn't accidentally drag spam into the destination — exclude it in the batch settings.

6. Run the bulk migration in batches

   Migrate in batches of 20–30 mailboxes. Microsoft throttles aggressively above 10 concurrent IMAP sessions per tenant from a single source IP; Gmail caps inbound IMAP connections at 15 per destination account. Your effective parallelism is the lower of the two. Keep batch size small enough that a single failure doesn't take down the run. Monitor source throttling with Get-ThrottlingPolicy if you suspect issues.

7. Cut MX records to Google

   Once the bulk sync is done, update MX records to point at Google (aspmx.l.google.com priority 1, plus the four altN.aspmx.l.google.com entries). Wait for the TTL to expire — at 300 seconds you're looking at five to ten minutes for most clients to catch up. Then run a delta sync to catch anything that arrived at Outlook during the DNS switch.

8. Validate, configure send-as, and decommission

   For users who need to keep replying from their old Outlook address (typical during a brand transition), set up Gmail's Send mail as feature with SMTP credentials to the source. Verify every migrated mailbox by sending a round-trip message. Only suspend the Outlook accounts after you have a confirmed go from the user. Keep them suspended for 30 days minimum.

Provider-specific gotchas#

The differences between Outlook variants and Gmail's quirks are where most weekend migrations lose their nerve.

Modern Authentication is mandatory for most M365 tenants. Since October 2022 Microsoft has rolled out Basic Auth deprecation for Exchange Online by default. If your migration tool only supports Basic Auth, you need to either pick a tool that supports OAuth or temporarily create an authentication policy that re-enables Basic Auth on the migrating mailboxes — and that requires a tenant exception that takes a support ticket to renew. Plan for OAuth.

Folder-to-label mapping flattens behaviour users rely on. In Outlook, a message lives in one folder. In Gmail, a message can carry multiple labels. The migration creates one label per source folder and applies it to the right messages, but users won't suddenly start multi-labeling their mail post-migration. Train them on the difference or expect support tickets about "where did my folders go".

The Sent Items folder name conflict. Outlook calls it Sent Items. Gmail calls it Sent Mail. A naive IMAP migration creates both folders, splits sent mail across them, and confuses everyone. Configure your migration tool to map Sent Items to Gmail's special [Gmail]/Sent Mail folder. The same trap applies to Deleted Items versus Trash and Junk Email versus Spam.

Categories and follow-up flags don't survive IMAP. Outlook's coloured categories and follow-up flags are stored in Exchange-specific MAPI properties IMAP doesn't expose. They are gone after migration, full stop. Tell users in advance so they don't think the migration "broke" them.

Outlook.com accounts get rate-limited harder than M365. Consumer Outlook.com has a per-account IMAP throttle that kicks in around 3–4 concurrent connections. M365 corporate tenants are more generous. If you're migrating a mixed bag, don't use the same parallelism settings for both. Run consumer accounts at 2 concurrent connections each, corporate at 5.

Common errors#

The errors you'll see in production, and what they mean:

• AUTHENTICATIONFAILED — For Outlook.com, the app password is wrong or has been revoked. Regenerate it from the user's security page. For M365, the OAuth token has expired, the Entra app permissions weren't consented, or Modern Auth isn't enabled on the user. Check the app registration first.
• Too many simultaneous connections — Gmail or Outlook.com is rejecting new connections. For Outlook.com, you're past the consumer per-account ceiling — drop to 2 concurrent sessions. For Gmail, the destination account has hit its 15-connection inbound IMAP cap; the Gmail app password troubleshooting guide covers the credential side as well.
• STARTTLS handshake failed — Either your tool is trying STARTTLS on port 143 when it should be using SSL on 993, or the source endpoint has a certificate problem. Confirm outlook.office365.com:993 for corporate and imap-mail.outlook.com:993 for consumer.
• OAuth2 token expired — Your Entra ID app's access token has lapsed. Refresh tokens are valid for 90 days by default but admins sometimes shorten that with conditional access policies. Re-authenticate the migration tool.
• Folder UTF-7 conversion error — A folder on the source has a character (often emoji or non-Latin script) the IMAP encoding can't translate. Rename the folder in Outlook on the web, wait for the IMAP cache to refresh (a few minutes), and re-run.
• Message too large for destination — Gmail's hard message size limit is 25 MB for sending and roughly 50 MB for receiving via IMAP. Anything larger gets skipped in transit. Note them, pull manually if needed.

Communicating with your users#

The Outlook-to-Gmail switch is harder on users than the reverse because Gmail's interface is more opinionated. Set expectations early or pay for it in tickets.

Two weeks before cutover, send a note covering three things only: the date, what their new login will be (user@yourcompany.com typically, no change needed), and a one-line warning that "folders will become labels — your mail won't be lost, but the menu will look different". Resist the urge to explain labels in detail; nobody reads it.

One week before, send a five-minute video or screenshot deck showing the new Gmail interface with their existing folder structure visible as labels. The single biggest reason users say a migration "didn't work" is that they couldn't find their folder tree on day one. Show them where to look.

The night before, send a brief reminder with the cutover window and a "do not delete anything from Outlook" line. Outlook users have ingrained habits around clearing inbox; deletions during the delta sync are the worst data-loss vector.

On cutover day, send a "we've started" message at the start of the window, and a "you're live, here's how to access" message when it's done. Include the Gmail web URL, links for installing Gmail on iOS and Android, and a quick note about set-up for desktop clients if your team uses Apple Mail or Thunderbird. The complete email migration guide has a reusable comms template.

After cutover, watch your ticket queue closely for the first 72 hours. Most issues will be variations on "I can't find folder X" — answer them once, then publish the answer as an FAQ and link to it from every reply. Compare your run-up notes against the broader Google Workspace migration guide to lock in lessons for the next batch.