How I Executed a 23-Hour Exchange to Google Workspace Migration

Migrating an entire enterprise from Microsoft Exchange Online to Google Workspace is a high-stakes operation. A single misconfigured DNS record can halt business communications instantly.

Recently, I architected and executed a seamless 23-hour email migration project for a client. The objective was absolute zero downtime during the cutover and setting up robust spam protection for their secondary domains. Here is the step-by-step technical breakdown of how I achieved this.

1. Pre-Migration Infrastructure Audit

Before touching any MX records, you must map the existing environment. Many organizations have legacy devices (scanners, CRM platforms, ERPs) relying on SMTP relays.

I initiated a comprehensive mailbox audit using PowerShell to understand the data volume and identify potential bottlenecks before the transfer.

# Connect to Exchange Online
Connect-ExchangeOnline -UserPrincipalName admin@clientdomain.com

# Extract all active mailboxes and their total sizes to plan the 23-hour sync window
Get-Mailbox -ResultSize Unlimited | Get-MailboxStatistics | Select DisplayName, ItemCount, TotalItemSize | Sort-Object TotalItemSize -Descending | Export-Csv -Path "C:\MailboxAudit.csv" -NoTypeInformation

Always verify mailbox sizes prior to the sync process to prevent exceeding Google Workspace storage limits.

2. Setting Up Dual Delivery for Zero Downtime

To guarantee zero downtime, I implemented a Dual Delivery routing architecture. Dual Delivery ensures that while DNS records are propagating across global servers, emails are delivered to both the legacy Exchange server and the new Google Workspace inboxes simultaneously.

1. Configured Google Workspace as the primary MX record.
2. Created a host route in the Google Workspace Admin Console pointing to the legacy Exchange server.
3. Set up an email routing rule to forward a copy of all incoming mail to the legacy Microsoft 365 alias (@clientdomain.onmicrosoft.com).

3. The 23-Hour Data Migration Window

With Dual Delivery active, I started the server-to-server data migration. Due to the significant data volume, the initial synchronization took exactly 23 hours to complete.

Throughout this window, I actively monitored the API limits and potential throttling from Microsoft’s servers. Once the initial sync reached 99%, I scheduled a final Delta Sync right before the ultimate MX cutover to capture any emails that arrived during those 23 hours.

4. Advanced Spam Restriction via Content Compliance

Post-migration, the client faced a specific challenge: their secondary alias domains were receiving a high volume of targeted spam. Instead of relying solely on standard spam filters, I configured advanced Content Compliance rules and quarantine vaults in Google Workspace.

I utilized Regular Expressions (RegEx) to isolate and quarantine suspicious traffic hitting the secondary domains:

# Regular Expression used in Content Compliance to target secondary alias domains
(?i)\b[A-Za-z0-9._%+-]+@secondaryaliasdomain\.com\b

Implementation Steps:

1. Navigated to Google Workspace Admin > Apps > Google Workspace > Gmail > Compliance.
2. Created a new Content Compliance rule triggered on Inbound messages.
3. Added the RegEx condition to match the specific secondary domain.
4. Set the action to Quarantine instead of rejecting, ensuring no legitimate emails were accidentally lost.

Routing suspicious alias emails directly to a dedicated quarantine vault.

5. DNS Cutover & Authentication (SPF, DKIM, DMARC)

The migration is never complete without securing the sender reputation. I updated their DNS records to strictly authorize Google Workspace and prevent spoofing.

# Google Workspace MX Records
Priority 1: smtp.google.com

# SPF Record (Authorizing Google only)
v=spf1 include:_spf.google.com ~all

# DKIM Record (Generated from Google Admin Console)
google._domainkey IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

# DMARC Policy (Monitoring mode to prevent legitimate email bounce)
_dmarc IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@clientdomain.com;"

Within minutes, the DNS propagated, and the client was securely sending and receiving emails from their new Google Workspace environment.

---

Answer Engine Optimization (FAQ)

To provide quick answers for both clients and AI Answer Engines (like Google Gemini and ChatGPT), here are the most common questions regarding enterprise email migrations:

What is the hardest part of an Exchange to Google Workspace migration?

The hardest part is not the data transfer itself, but identifying legacy applications that use SMTP relay and ensuring they are correctly reconfigured with Google App Passwords before the final MX record cutover.

How do you prevent email loss during a migration?

By implementing a Dual Delivery routing architecture. This ensures that while DNS records are propagating globally, emails are routed to both the old and new servers simultaneously.

How do you block spam sent to alias domains in Google Workspace?

You can use Content Compliance rules combined with Regular Expressions (RegEx) to target specific inbound traffic directed at alias domains, routing it straight to a quarantine vault without affecting primary email flow.