Google Workspace to Microsoft 365 Email and Calendar Migration: Technical Implementation Guide

Email and calendar migration is the most critical and technically complex component of Google Workspace to Microsoft 365 transitions. A poorly executed email migration results in lost messages, broken calendar appointments, missing contacts, and days of user frustration. This technical guide provides step-by-step implementation procedures for migrating email, calendar, and contacts with zero data loss and minimal disruption.

You'll learn MX record configuration for coexistence, mail routing strategies, IMAP vs. API migration approaches, delta sync procedures, calendar free/busy setup, and comprehensive validation testing. This guide assumes you have basic familiarity with Google Workspace Admin Console, Microsoft 365 Exchange Admin Center, and DNS management.

Pre-Migration Technical Preparation

Step 1: Mailbox Size and Volume Assessment

Google Workspace Admin Console Audit

1. Go to Reports → Email log search → Storage
2. Export report showing mailbox size per user
3. Identify users with 10GB+ mailboxes (slower migration)
4. Identify users with 50GB+ (may hit Microsoft 365 limits)

Calculate Total Migration Time

• IMAP migration: ~1GB per hour per mailbox (conservative estimate)
• Example: 50 users, average 5GB mailbox = 250GB total = 250 hours = 10+ days
• API-based tools (MigrationWiz): 3-5x faster = 2-4 days
• Plan for 2-3x buffer time for issues and delta syncs

Step 2: Microsoft 365 Tenant Configuration

Verify Domain Ownership

1. Microsoft 365 Admin Center → Settings → Domains → Add domain
2. Enter your domain (company.com)
3. Add TXT record to DNS: MS=ms12345678 (verify ownership)
4. Wait for verification (can take 15-60 minutes)
5. Do NOT set as default domain yet (keep .onmicrosoft.com default during migration)

Create User Accounts

# PowerShell: Bulk create users from CSV
# CSV format: FirstName,LastName,Email,Password
Import-Csv "users.csv" | ForEach-Object {
    New-MsolUser -DisplayName "$($_.FirstName) $($_.LastName)" -UserPrincipalName $_.Email -Password $_.Password -ForceChangePassword $false -UsageLocation "US" -LicenseAssignment "company:ENTERPRISEPACK"
}

Configure Exchange Online Mailboxes

# PowerShell: Verify all users have mailboxes
Get-Mailbox -ResultSize Unlimited | Select DisplayName, PrimarySmtpAddress

# Enable mailbox if missing
Enable-Mailbox -Identity "user@company.com"

Step 3: DNS Configuration for Coexistence

Current State (Before Migration)

• MX records point to Google Workspace (smtp.gmail.com)
• SPF record includes Google: v=spf1 include:_spf.google.com ~all
• DKIM keys are Google's

Coexistence Configuration

1. Keep MX records pointing to Google during migration (don't change yet)
2. Add Microsoft 365 to SPF: v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all
3. Enable DKIM for Microsoft 365: Generate DKIM keys in Exchange Admin Center, add CNAME records to DNS
4. Keep DMARC permissive during coexistence: v=DMARC1; p=none; rua=mailto:dmarc@company.com

Email Migration: IMAP vs. API Approaches

Option 1: Native IMAP Migration (Free, Limited)

When to Use: Small migrations (under 50 users), simple requirements, tight budget

Limitations:

• Migrates email only (no calendar, contacts, or labels)
• No delta sync (must migrate entire mailbox at once)
• Slow (1GB/hour per mailbox)
• Labels become folders (nested labels flatten)

Implementation Steps:

1. Enable IMAP in Google Workspace: Admin Console → Apps → Google Workspace → Gmail → Enable IMAP for all users
2. Exchange Admin Center → Migration → IMAP migration → New
3. Upload CSV with user mappings: EmailAddress,UserName,Password
4. Configure migration endpoint: imap.gmail.com, port 993, SSL enabled
5. Start migration, monitor progress in dashboard
6. Migration runs continuously until complete (no cutover needed if using coexistence)

CSV Format:

EmailAddress,UserName,Password
john@company.com,john@company.com,apppassword123
jane@company.com,jane@company.com,apppassword456

Google App Passwords: If 2FA enabled (required for secure migrations), generate app-specific passwords: Google Account → Security → App passwords → Generate

Option 2: API-Based Migration (Recommended)

Tools: BitTitan MigrationWiz, Quest On Demand, SkyKick

Advantages:

• Migrates email, calendar, contacts, and labels
• Delta sync: migrate in stages, minimizes cutover downtime
• 3-5x faster than IMAP (uses Google API instead of IMAP protocol)
• Advanced permission mapping and error handling
• Detailed reporting and verification

Implementation Steps (BitTitan MigrationWiz Example):

1. Create MigrationWiz project: Log into BitTitan portal, create new Google Workspace to Microsoft 365 project
2. Configure source endpoint: Authorize MigrationWiz to access Google Workspace via OAuth (admin consent required)
3. Configure destination endpoint: Provide Microsoft 365 admin credentials or create migration endpoint in Exchange Online
4. Create user mappings: Import CSV or auto-discover users. Map Gmail address to Outlook address (usually identical).
5. Configure migration settings: Email, calendar, contacts, Drive (optional)
6. Pre-stage migration: Migrate historical data (everything older than 7 days)
7. Delta sync migrations: Run daily delta syncs to catch new mail during coexistence
8. Cutover migration: Final sync on cutover weekend, switch MX records

Migration Wave Strategy

Pilot Wave (10-20 users, Week 1)

• IT team + volunteer early adopters
• Full migration: email, calendar, contacts
• Test all functionality before proceeding
• Gather feedback, adjust procedures

Production Waves (By Department or Location)

• Wave 1: 20% of users (Week 2-3)
• Wave 2: 30% of users (Week 3-4)
• Wave 3: 30% of users (Week 4-5)
• Wave 4: Remaining 20% (Week 5-6)
• Each wave includes pre-stage + cutover + verification

Calendar Migration and Free/Busy Coexistence

Calendar Migration Challenges

• Recurring meetings: Complex recurrence patterns may not migrate perfectly
• Meeting attendees: If attendees not migrated yet, they see wrong meeting info
• Room resources: Google Calendar rooms don't map cleanly to Exchange rooms
• Time zones: Timezone conversions can cause off-by-one-hour errors

Calendar Migration Approach

Option 1: Migrate with Email (Recommended)

• Use API-based tool that handles calendar (MigrationWiz, Quest, SkyKick)
• Calendar migrates alongside email
• Past and future events transferred
• Recurring meetings preserved
• Meeting responses (accept/decline) preserved

Option 2: Manual Export/Import (Small migrations only)

• Export Google Calendar to .ics file: Calendar Settings → Import & Export → Export
• Import to Outlook: File → Open & Export → Import/Export → Import .ics file
• Works but loses recurring meeting links to attendees
• Only viable for under 10 users

Free/Busy Coexistence Setup

Why Free/Busy Matters: During coexistence, users on Outlook need to see availability of users still on Google Calendar (and vice versa) for meeting scheduling.

Exchange to Google Calendar Free/Busy

# PowerShell: Configure Exchange to query Google Calendar
$TargetSharingEpr = "https://www.google.com/calendar/feeds/"
Set-OrganizationRelationship -Identity "Google" -TargetSharingEpr $TargetSharingEpr -DomainNames "company.com" -FreeBusyAccessEnabled $true -FreeBusyAccessLevel LimitedDetails

Google Calendar to Exchange Free/Busy

1. Google Workspace Admin Console → Apps → Google Workspace → Calendar
2. Sharing settings → External sharing options
3. Enable "Share all information, but outsiders can't change calendars"
4. Configure Microsoft 365 as trusted domain for free/busy queries

Limitation: Only shows free/busy (not meeting subject/details). Sufficient for scheduling during coexistence period.

Contact Migration

Google Contacts Architecture

• Personal contacts: Each user's individual contacts
• Directory contacts: Org-wide contacts from Google Workspace directory
• Contact groups: Similar to Outlook contact lists

Contact Migration Methods

API-Based Tool (Included in MigrationWiz, etc.)

• Migrates personal contacts during user migration
• Contact groups preserved as Outlook contact lists
• Profile photos migrated
• Custom fields mapped to closest Outlook equivalent

Manual Export/Import (Backup Method)

1. Google Contacts → Export → Google CSV format
2. Outlook → File → Import/Export → Import from another program → CSV
3. Map fields (Google "Name" → Outlook "Full Name", etc.)
4. Time-consuming but works for small user counts

Global Address List (GAL)

GAL automatically populates in Exchange Online from Azure AD users. No manual migration needed. Users see full employee directory in Outlook after accounts created.

Mail Routing and Coexistence

Coexistence Architecture

• MX records: Point to Google Workspace
• Incoming mail: Arrives at Gmail servers first
• Mail routing: Gmail forwards mail for migrated users to Microsoft 365
• Outbound mail: Both Gmail and Exchange send directly (no relay)

Configure Google Workspace Mail Routing

Step 1: Create Routing Rule for Migrated Users

1. Google Workspace Admin Console → Apps → Google Workspace → Gmail
2. Routing → Add route
3. Name: "Forward to Microsoft 365"
4. Affected users: Specific organizational unit (OU) containing migrated users OR specific user list
5. Route destination: Change route → company-com.mail.protection.outlook.com
6. Options: Suppress bounces, Don't perform MX lookup

Step 2: Verify Mail Flow

1. Send test email to migrated user from external address (Gmail, Outlook.com)
2. Verify email arrives in Microsoft 365 mailbox
3. Check message headers to confirm routing path: Gmail → Microsoft 365
4. Test reply: verify outbound mail from Microsoft 365 delivers correctly

Cutover: Switching MX Records

When to Cutover: After all users migrated, or when majority migrated and ready to decommission Gmail

Cutover Procedure:

1. Final delta sync: Run final migration sync to catch last messages
2. Update MX records: Change MX to point to Microsoft 365 (company-com.mail.protection.outlook.com, priority 0)
3. DNS propagation: Wait 1-24 hours for DNS to propagate globally
4. Monitor mail flow: Check Exchange message trace to confirm inbound mail arriving directly at Microsoft 365
5. Disable Gmail routing: Remove routing rule from Google Workspace (mail no longer needs forwarding)

MX Record Example:

# Before (Google Workspace)
company.com    MX    1    aspmx.l.google.com
company.com    MX    5    alt1.aspmx.l.google.com
company.com    MX    5    alt2.aspmx.l.google.com

# After (Microsoft 365)
company.com    MX    0    company-com.mail.protection.outlook.com

Migration Validation and Testing

Pre-Cutover Validation Checklist

Email Tests

• ✓ Send test email from external address → migrated user (receives in Outlook)
• ✓ Migrated user sends email → external address (delivers, correct sender address)
• ✓ Migrated user sends to non-migrated user on Gmail (delivers)
• ✓ Non-migrated Gmail user sends to migrated user (delivers to Outlook)
• ✓ Test large attachment (25MB+) inbound and outbound
• ✓ Verify message threading/conversations preserved

Calendar Tests

• ✓ Historical appointments appear in Outlook calendar
• ✓ Future meetings preserved with correct time/attendees
• ✓ Recurring meetings display correctly
• ✓ Room resources bookable from Outlook
• ✓ Free/busy visible for non-migrated users still on Google Calendar
• ✓ Meeting invites from Outlook deliver to Gmail users (and vice versa)

Contact Tests

• ✓ Personal contacts migrated and accessible in Outlook
• ✓ Contact photos displayed
• ✓ Contact groups/lists intact
• ✓ GAL shows all company employees with accurate information

Mobile Device Tests

• ✓ iOS Mail app connects to Exchange ActiveSync
• ✓ Android Outlook app connects and syncs
• ✓ Calendar and contacts sync to mobile devices
• ✓ Push notifications for new email working

Post-Cutover Validation

PowerShell: Verify Mail Flow

# Check inbound mail is arriving at Exchange Online
Get-MessageTrace -StartDate (Get-Date).AddHours(-2) -EndDate (Get-Date) |
    Where-Object {$_.FromIP -notlike "*protection.outlook.com*"} |
    Select RecipientAddress, SenderAddress, Subject, Status

# Should show external mail arriving directly at Exchange (not via Gmail)

Monitor for Common Post-Cutover Issues

• Bounced messages (check NDRs in Exchange message trace)
• Delayed delivery (DNS propagation lag)
• Missing emails (run final delta sync if messages sent during cutover window)
• Authentication failures (mobile devices not reconfigured)

Troubleshooting Common Migration Issues

Issue 1: "Migration Stuck at 0%"

Symptoms: IMAP migration starts but shows 0% progress for hours

Causes:

• Incorrect password or app password expired
• IMAP not enabled in Google Workspace
• Firewall blocking outbound IMAP connections from Microsoft 365

Solutions:

• Verify IMAP enabled: Gmail Settings → Forwarding and POP/IMAP → Enable IMAP
• Generate new app password if using 2FA
• Test IMAP connection from Outlook desktop client to confirm connectivity
• Check Exchange migration logs: Get-MigrationBatch | Get-MigrationUserStatistics | FL

Issue 2: "Calendar Events Show Wrong Time"

Symptoms: Meetings appear 1-2 hours off after migration

Causes:

• Timezone conversion error during migration
• User's Outlook timezone set incorrectly
• Daylight saving time handling mismatch

Solutions:

• Verify Outlook timezone: File → Options → Calendar → Time zones (should match Google Calendar)
• Re-migrate calendar with timezone preservation option enabled (if tool supports)
• For critical meetings, manually recreate with correct time

Issue 3: "Some Emails Missing After Migration"

Symptoms: User reports certain emails or folders didn't migrate

Causes:

• Emails in Gmail "All Mail" but not in labeled folders (IMAP doesn't sync "All Mail")
• Migration cutoff date excluded recent emails
• Large attachments failed to migrate
• Corrupted emails in Gmail

Solutions:

• Run delta sync to catch emails received after initial migration
• Check migration logs for skipped items and error codes
• For IMAP: ensure all emails are labeled/foldered in Gmail before migration
• Manually export/import missing emails as .mbox or .pst

Issue 4: "Mail Routing Not Working"

Symptoms: Email sent to migrated user bounces or goes to Gmail instead of Outlook

Causes:

• Google Workspace routing rule not configured correctly
• MX records not updated or DNS propagation incomplete
• Typo in Exchange mail routing address

Solutions:

• Verify routing rule in Google Admin Console points to correct Exchange endpoint
• Test with MXToolbox or dig to confirm MX records resolving correctly
• Check Exchange message trace for delivery attempts
• Send test from external address, review full message headers to trace routing path

Performance Optimization

Accelerating Migration Speed

Parallel Migrations

• Most tools support concurrent migrations (10-50 users simultaneously)
• IMAP: Limited by Exchange throttling (~10 concurrent connections)
• API-based: Can migrate 50-100 users in parallel
• Bottleneck: Usually Google API rate limits, not Microsoft side

Pre-Stage Large Mailboxes

• Identify users with 20GB+ mailboxes
• Start their migrations 1-2 weeks before their wave
• Run delta syncs daily until cutover
• Prevents large mailboxes from delaying entire wave

Archive Old Email Before Migration

• Move email older than 2-3 years to archive mailbox or cold storage
• Reduces primary mailbox size by 30-60%
• Faster migration, smaller Exchange mailbox (better performance)
• Users access archive via Outlook Archive or compliance search if needed

Post-Migration Cleanup

Week 1-2 Post-Cutover

• Keep Google Workspace mailboxes active but read-only (forward all mail to Microsoft 365)
• Users can access Gmail web for reference during transition
• Monitor for any routing issues or missing data reports

Week 3-4 Post-Cutover

• Disable Gmail mailboxes (users can't send from Gmail)
• Maintain Google Workspace licenses for Drive access if needed
• Begin Google Vault export for compliance/archival

Month 2-3 Post-Cutover

• Export all Google Vault data for long-term archive
• Delete Google Workspace user accounts
• Cancel Google Workspace licenses
• Keep domain associated with Google for 3-6 months minimum (allows late-arriving mail to forward)

Conclusion: Technical Excellence Ensures Smooth Migration

Email and calendar migration is where most Google Workspace to Microsoft 365 projects succeed or fail. Follow these technical procedures, validate thoroughly at each stage, and don't rush. A well-executed migration is invisible to users — email just works in the new system. A poorly executed migration causes data loss, meeting chaos, and weeks of user complaints.

Key technical principles:

• Always pilot with 10-20 users before production migration
• Use API-based tools (not IMAP) for 50+ users
• Implement coexistence, don't big-bang cutover
• Validate mail routing, calendar, and contacts at each wave
• Keep Google Workspace active for 30-60 days post-cutover as safety net