Migrate Office 365 to Google Workspace: Complete Cutover Guide (2026)

Migrating an organization from Exchange Online to Google Workspace requires coordination across identity directories, DNS records, and email synchronization pipelines.

To ensure continuous business operations during the transition, administrators follow a staged cutover methodology: pre-synchronizing historical mail, switching mail routing records, executing a final delta synchronization, and handling shared resources.

┌────────────────────────────────────────────────────────┐
│  M365 TO GOOGLE WORKSPACE CUTOVER LIFECYCLE            │
├────────────────────────────────────────────────────────┤
│  PHASE 1: Tenant Discovery & Directory Provisioning    │
│             │                                          │
│  PHASE 2: Historical Pre-Sync (Cold Mail Data)         │
│             │                                          │
│  PHASE 3: DNS Cutover (MX & SPF Records to Google)     │
│             │                                          │
│  PHASE 4: Final Delta Sync & Shared Mailbox Mapping    │
└────────────────────────────────────────────────────────┘

Pre-Migration Architecture Checklist

Complete these foundational requirements before initiating data synchronization:

1. Provisioning Target Accounts

Create all user accounts, domain aliases, and Google Groups in the Google Workspace Admin Console (admin.google.com). Verify that primary email addresses align with source User Principal Names (UPNs) in Microsoft 365.

2. Lowering DNS Record TTLs

At least 48 hours prior to your scheduled cutover window, lower the Time-To-Live (TTL) on your domain's MX, SPF, and autodiscover records to 300 seconds (5 minutes). This ensures that when MX records are pointed to Google, external mail servers recognize the routing change rapidly.

3. Entra ID App Registration (Source Tenant)

To allow administrative access without prompting users for passwords:

1. Open the Microsoft Entra admin center > App registrations > New registration.
2. Name the application Workspace-Migration-Connector.
3. Under API permissions, grant application permissions for Microsoft Graph:

• Mail.Read / Mail.ReadWrite
• Calendars.Read
• Contacts.Read
• User.Read.All

4. Click Grant admin consent.
5. Generate a Client Secret and record the Application ID, Directory (tenant) ID, and Secret value.

4. Google Cloud Service Account (Target Tenant)

In the Google Cloud Console (console.cloud.google.com), create a project and enable the Gmail API, Google Calendar API, and People API. Generate a Service Account JSON key, enable Domain-Wide Delegation, and authorize these scopes in the Google Workspace Admin Console under Security > API controls:

• https://mail.google.com/
• https://www.googleapis.com/auth/calendar
• https://www.googleapis.com/auth/contacts

DNS & Authentication Transition Matrix

During coexistence and cutover, configure DNS records carefully to prevent delivery failures and spoofing rejections:

The 4-Phase Migration Methodology

┌────────────────────────────────────────────────────────┐
│  PRISM DIRECT CLOUD TENANT-TO-TENANT STREAMING         │
├────────────────────────────────────────────────────────┤
│  [Microsoft Graph API] (Source Tenant)                 │
│             │ TLS 1.3 Streaming Pipeline               │
│             ▼                                          │
│  [Prism Cloud Migration Controller]                    │
│             │ TLS 1.3 Streaming Pipeline               │
│             ▼                                          │
│  [Google Workspace API] (Target Tenant)                │
└────────────────────────────────────────────────────────┘

Phase 1: Historical Pre-Synchronization

Initiate an initial data sync 1 to 2 weeks before the planned cutover to transfer messages older than 30 days. Because historical mail is static, this bulk payload transfers in the background while users continue working inside Microsoft 365.

Phase 2: Live DNS Cutover

During an off-peak maintenance window (e.g., Friday evening), update your authoritative DNS MX records to point to Google:

• 1 ASPMX.L.GOOGLE.COM.
• 5 ALT1.ASPMX.L.GOOGLE.COM.
• 5 ALT2.ASPMX.L.GOOGLE.COM.
• 10 ALT3.ASPMX.L.GOOGLE.COM.
• 10 ALT4.ASPMX.L.GOOGLE.COM.

Update your SPF TXT Record to reflect Google servers:

v=spf1 include:_spf.google.com ~all

New incoming emails will begin delivering directly to Google Workspace inboxes as DNS changes propagate.

Phase 3: Final Delta Synchronization

Run a final delta sweep using the migration engine. The software compares message hashes and RFC Message-ID headers to migrate only newly received emails, updated calendar invites, and modified contacts created since the initial sync.

Phase 4: Shared Mailbox Ingestion

Exchange Online shared mailboxes can be mapped to Google Groups (Collaborative Inboxes) or dedicated Google Workspace user accounts depending on your team's workflow requirements and compliance needs.

Managing Microsoft Graph & EWS Throttling

When migrating multiple active mailboxes concurrently, Microsoft 365 may enforce throttling limits, returning HTTP 429 Too Many Requests or HTTP 503 Server Busy.

MICROSOFT 365 GRAPH API QUOTA CONSIDERATIONS
============================================
- Concurrency Threshold: ~4 concurrent requests per individual mailbox
- Tenant Rate Threshold: Up to 10,000 requests per 10-minute window
- Mitigation: Adaptive backoff with jittered retry intervals (5s -> 15s -> 45s)

To minimize throttling delays:

1. Distribute worker threads across multiple Entra ID App registrations when migrating more than 250 mailboxes.
2. Schedule heavy migrations during off-peak hours and weekends.
3. Exclude unneeded folders (such as Deleted Items, Junk, and sync logs) from the migration scope.

Resolving Legacy Exchange X.500 Address Bounces

A common post-migration issue occurs when users reply to historical calendar invites or emails in Google Workspace and receive Non-Delivery Reports (NDRs) stating: 550 5.1.11 RESOLVER.ADR.ExRecipNotFound.

This happens because Exchange internally addresses users via proprietary X.500 Distinguished Names rather than standard SMTP addresses.

Resolution Steps:

1. Export all LegacyExchangeDN values from Exchange Online PowerShell before decommissioning:

   Get-Mailbox -ResultSize Unlimited | Select-Object DisplayName, UserPrincipalName, LegacyExchangeDN | Export-Csv C:\Migration\legacy_dns.csv

2. Add each user's prior LegacyExchangeDN as an X.500 address alias in Google Workspace, or configure routing rules to direct legacy strings to active user accounts.

Technical Comparison: Migration Approaches

For an architectural breakdown and pricing comparison between flat workstation licensing and per-user subscription fees, review our BitTitan MigrationWiz Alternative Guide.

4 Critical Pitfalls to Avoid

1. Premature License Cancellation: Keep Microsoft 365 licenses active for at least two weeks post-cutover because third-party senders with cached DNS routes may continue delivering to Microsoft servers during propagation.
2. Timezone Calendar Offsets: Ensure user timezones are verified in both Microsoft 365 and Google Workspace before synchronization begins to prevent appointment offsets.
3. Litigation Hold & Dumpster Archives: Emails stored in Exchange Online's hidden Recoverable Items container do not migrate via standard IMAP. Use full Graph/MAPI extraction to preserve compliance records.
4. Third-Party Application Relays: Update multi-function printers, scanners, CRM systems, and internal servers to authenticate via Google's SMTP relay (smtp-relay.gmail.com) instead of smtp.office365.com.

Frequently Asked Questions (FAQs)

Will existing email folder hierarchies be preserved in Google Workspace?

Yes. Exchange Online folder hierarchies convert into nested Google Workspace labels while preserving read/unread states and conversation threading.

How does the tool handle large attachments over 25 MB?

Google Workspace rejects incoming email payloads exceeding 25 MB. The migration engine logs oversized messages in an exceptions CSV, allowing administrators to extract attachments locally or stage them in Google Drive.

What happens to Microsoft Teams chat history during email migration?

Teams chat history is stored in hidden non-IPM folders within individual Exchange Online mailboxes (\Conversation History\Team Chat). Standard migration protocols do not transfer these to Gmail. If Teams records must be retained for compliance, export the mailbox to PST using Prism Office 365 Backup Tool prior to tenant deprovisioning.

Summary

Executing an enterprise cutover from Microsoft 365 to Google Workspace requires clear sequencing: directory provisioning, historical pre-sync, DNS cutover, and delta synchronization. By adhering to proper DNS TTL management and API throttling controls, organizations achieve a seamless transition. For offline archiving and compliance preservation prior to tenant decommissioning, Prism Office 365 Backup Tool provides standalone PST extraction capabilities.

Related Guides:

• How to Backup Office 365 Mailboxes to PST Locally
• How to Migrate PST to Google Workspace Domain-Wide