Gmail to Outlook migration

A Gmail message can carry any number of labels; an Exchange message lives in exactly one folder. Every migration resolves this collision somehow, and the default resolution is arbitrary. A message labelled both Clients and Invoices lands in one of them, and which one depends on ordering rather than on meaning.

We agree the mapping in discovery. Shared, structural labels become folders. Cross-cutting labels that describe status rather than subject become Outlook categories, which is the closest true equivalent. Individual filing habits are documented and dropped rather than migrated into a folder tree nobody else understands.

Generic IMAP does not transfer Gmail rules. Microsoft’s dedicated Google Workspace workflow can migrate supported rules, disabled by default; review conditions, actions and business-critical routing before enabling them in Outlook.

We export every user's filter set before cutover and hand it back as a readable list, then rebuild the top rules as Outlook rules for the users who depend on them. Identifying those users is a five-minute conversation in discovery and saves the first week after cutover.

Gmail delegation and Exchange delegation look similar and behave differently, particularly around sent-item placement and calendar rights. They cannot be copied; they are rebuilt from a report of who currently has access to what. That report is also the moment most organisations discover access that should have been revoked years ago.

Shared mailboxes are the other common surprise. Addresses that exist in Google as a group with delivery enabled often need to become an Exchange shared mailbox rather than a distribution list, because people expect a shared history rather than individual copies.

The interface change is larger than the data change, and it is the part nobody budgets for. Search behaves differently, threading behaves differently, and the keyboard shortcuts a heavy Gmail user relies on do not exist. A single one-page note sent before cutover explaining these three things reduces first-week support volume noticeably.

We supply that note as part of the project, along with a written runbook of what changed and why, so your internal support has an answer ready rather than discovering each difference alongside the user reporting it.