Google Workspace to Microsoft 365 Email Migration Plan

Moving a company's email from Google Workspace to Microsoft 365 is not a settings toggle — it's a domain-level cutover, and the failure modes are downtime and lost mail, not cosmetic differences. This google workspace to microsoft 365 email migration plan follows the sequence Microsoft's own Exchange admin center actually runs: provision the tenant, migrate mail while Workspace stays live, then cut the MX record last.

Two things make this migration higher-stakes than switching browsers or file storage. Google retired Basic Auth for Gmail years ago, so every migration tool has to authenticate with OAuth — a plain username-and-password IMAP connection is rejected outright. And once you flip MX, every mail server on the internet finds your new mailboxes on its own schedule, not yours; there's no gentle ramp.

This is a planning guide, not a click-by-click walkthrough — both vendors change their admin screens on their own release schedule, so it links to Microsoft's and Google's live documentation for the exact steps rather than restating a UI that will look different in six months.

What actually moves — and what doesn't#

Two different tools run this migration, and they carry different data. The automated Google Workspace migration in the Exchange admin center moves mail, contacts and calendar. Plain IMAP migration — pointed at imap.gmail.com — moves mail only.

Google Drive, Shared Drives, and Google Groups sit outside both tools entirely. Treat them as separate projects with their own timeline, not a checkbox inside the mail cutover.

Pre-migration checklist#

Most migration failures trace back to something skipped in this list, not a bug in the migration tool itself. Work through it in order — several items block the ones after them.

• Inventory every mailbox and its size in the Google Workspace Admin console (Reporting > Apps > Gmail), so you know which accounts will take longest to sync.
• Buy and assign a Microsoft 365 / Exchange Online license to every mailbox before touching the migration tool — an unlicensed mailbox can't receive migrated mail.
• Confirm someone on the project has edit access to the domain's DNS zone. MX, SPF, DKIM and CNAME records all change during this migration.
• Register an Azure AD app with the full_access_as_app application permission for the automated Google Workspace migration path, or set up per-mailbox OAuth consent for plain IMAP.
• In Google Cloud Console, create the service account and grant domain-wide delegation for the Gmail, Calendar and Contacts API scopes the migration will use.
• Pick the migration path up front: automated (mail, contacts and calendar) or plain IMAP (mail only, less setup, more to recreate by hand afterward).
• Drop the domain's MX and SPF TXT record TTL to under an hour, at least 72 hours before the planned cutover, so the eventual flip propagates fast.
• Tell staff the cutover date, and ask them to avoid moving calendar events or sending from delegated Gmail addresses during the cutover window itself.

The migration steps#

1. 1

   Lower the DNS TTL

   Three days before the batch runs, drop MX and SPF TXT record TTLs to under an hour. A short TTL is the only lever you have over how fast the eventual cutover propagates across the internet.

2. 2

   Provision users and licenses in Microsoft 365

   Create every mailbox with the exact primary email address it has in Google Workspace, and assign an Exchange Online plan to each one before the batch starts.

3. 3

   Verify the domain in Microsoft 365

   Add the domain in the Microsoft 365 admin center and add the TXT verification record it gives you. MX still points at Google — verification alone doesn't move mail.

4. 4

   Authorize API access on the Google side

   Grant the Azure AD app, or per-user OAuth consent, the Gmail, Calendar and Contacts scopes it needs in Google Admin console > Security > API controls. Basic Auth is not an option on either platform anymore.

5. 5

   Create the migration endpoint and batch

   In the Exchange admin center, add a migration batch, choose the Google Workspace or IMAP migration type, and point it at the Google service account credentials.

6. 6

   Run the initial sync, then keep delta-syncing

   The first pass can take hours to days depending on mailbox size. Run repeated delta batches afterward so newly arriving mail keeps catching up until you're ready to cut over.

7. 7

   Cut the MX record

   Point MX at Microsoft 365's mail exchanger only after a delta sync has completed with no items pending. This is the moment new mail stops arriving at Google.

8. 8

   Update SPF, DKIM and DMARC

   Add Microsoft 365's SPF include and DKIM selectors, and update the DMARC record once both are live. Leaving the old SPF include in place briefly is safer than removing it too early.

9. 9

   Hold a trailing verification window before decommissioning Workspace

   Keep Google Workspace licenses active — but not receiving new mail — for around 30 days, so a delayed complaint or a missed delegate account still has somewhere to check.

What breaks during a Workspace-to-M365 migration#

Most of the failure modes below are cutover-timing problems, not data-loss problems — which is also why they're avoidable with the sequence above.

Rollback plan#

A Workspace-to-M365 migration is close to fully reversible right up until you cut the MX record — and for a while after, if you kept Workspace licenses active. That's the entire rollback strategy: don't cancel the source until you're certain.

• Before MX cutover: there's nothing to roll back. Google Workspace is still authoritative for mail delivery; the migrated copy in Microsoft 365 is just that — a copy.
• Right after MX cutover: if delivery problems appear, point MX back at Google's mail servers. Propagation takes the same TTL-bound time it did going forward.
• Set a rollback trigger in advance — for example, more than a handful of missing-mail reports in the first four hours — and name who has the authority to call it.
• Don't delete or downgrade Google Workspace accounts for at least 30 days after cutover. A cancelled Workspace subscription is not reversible the way a DNS record is.

Doing it without downtime#

"No downtime" really means no dropped mail during the hours DNS is propagating — a global MX change reaches every mail server on its own schedule, not yours. Admins get close to zero by giving Google Workspace and Microsoft 365 a short overlap window where both can receive mail, rather than switching instantly.

One common pattern uses a routing subdomain — something like mail-migrate.yourdomain.com — with its own MX record pointed at Microsoft 365, so you can fully test the migrated mailboxes before touching the root domain's MX at all. Send and receive a handful of real test messages through it first.

When you're ready, cut the root domain's MX during the lowest-traffic part of your week, and keep a low-priority secondary MX pointed at Google for 24–48 hours as a safety net. Most resolvers pick up the new record within minutes; a few hold a cached lookup for the length of the old TTL — which is exactly why you shortened it days earlier.

Run one canary mailbox through the entire sequence a day ahead of everyone else. It surfaces broken delegate access, a missing calendar invite, or a stuck OAuth grant while the blast radius is one inbox, not the whole company.

Where AI Emaily fits once the migration is done#

This migration is about the mailbox, not the client that reads it — and that's exactly where the plan above stops being enough on its own. For a few weeks, some of your team will be live on Microsoft 365 while others are still finishing their batch on Google Workspace, and whoever handles support has to work across both.

AI Emaily connects to Gmail, Outlook and Exchange Online, and plain IMAP through the same OAuth-based account model this migration already requires, so a shared inbox doesn't care which platform a given mailbox landed on mid-cutover. It won't move your mail for you — that's the job of the steps above — but once everyone is settled on Microsoft 365, it's one inbox view instead of two logins and two sets of rules. We build AI Emaily, and we're naming it here because "which client survives a mid-migration split" is a real question this plan creates.