Email Migration

Question

Hi All,

Our company acquired another organization of approximately 500 users about four months ago. The acquired company currently uses Google Workspace, while our organization uses Microsoft 365 E5. Users currently use both Google Workspace and Outlook.

To maintain calendar interoperability during the transition period, we implemented a third-party calendar synchronization solution that synchronizes calendar events between Google Workspace and Microsoft 365 (Google → Outlook and Outlook → Google). This is a synchronization tool only and not a migration tool.

We have now started planning the migration of mailboxes from Google Workspace to Microsoft 365 using Microsoft FastTrack.

Current Status

• All Microsoft FastTrack prerequisites have been completed.
• I successfully completed a pilot migration for a single user by creating an Initial Synchronization event.
• Email migration from Google Workspace to Exchange Online completed successfully for the pilot user.
• I can see the migrated email data in Exchange Online.
• Calendar migration was excluded for the pilot user because calendar synchronization is already being handled by the third-party sync tool.

Planned Migration Approach for All Users

Migration Project Settings: My current migration settings are:

• Exclude Rules: No
• Exclude Calendars: No
• Exclude Contacts: No
• Exclude Tasks: Yes
• Exclude Permissions/Delegation: Yes

I recently changed the "Exclude Calendars" setting from Yes to No. I am also unsure whether tasks should be migrated and would appreciate guidance from anyone who has completed a similar Google Workspace to Microsoft 365 migration.

Calendar Synchronization

Before creating migration synchronization events for all users, I plan to disable the third-party calendar synchronization tool to prevent duplicate or looping calendar events between the two platforms. Is this the recommended approach?

Mailbox Migration

Before starting the migration, I plan to inform users that there should be no impact during the migration process and that they can continue using their existing Google Workspace mailboxes.

I plan to import a CSV containing a 1:1 mapping between Google Workspace users and Microsoft 365 users and then create Initial Synchronization events in batches of approximately 100 users.

My understanding of the FastTrack migration process is:

Initial Synchronization

• Migrates approximately 95% of mailbox data to Microsoft 365.

Incremental (Delta) Synchronization

• Runs periodically (approximately every 24 hours).
• Migrates new or changed items.
• Keeps the target mailbox synchronized with Google Workspace until cutover.

Is it recommended that users continue using Google Workspace until the Completion Event, or should they start using Outlook after the Initial Synchronization?

Completion Event

After validation, I plan to run the Completion Event, which I understand will:

• Perform the final synchronization.
• Complete the migration.
• Stop future synchronization activities.

Is my understanding correct?

Before initiating the Completion Event, I plan to instruct users to start using Outlook as their primary email client.

Mail Flow Cutover

Our Microsoft 365 MX records currently point to a secure email gateway rather than directly to Exchange Online.

My plan is:

1. Ask the Google Workspace administrator to update the domain MX records to point to our email gateway.
2. Configure recipient mapping on the email gateway so that mail addressed to migrated users is delivered to the corresponding Microsoft 365 mailbox.

I have the following questions:

• Do I need to add our email gateway SPF record to the acquired company's SPF record before cutover?
• Are there any DKIM or DMARC changes that should be made before or during the migration?
• Are there any recommended coexistence or mail-routing best practices?

Sending Email Using the Existing Domain

I am using Exchange SE Hybrid Environment. We create users in onprem and migrate to online. After migration, I want users to continue sending and receiving email using the same domain currently used in Google Workspace. What configurations are required on the Microsoft 365 / Exchange Online side to support this?

I would appreciate feedback from anyone who has completed a Google Workspace to Microsoft 365 migration of a similar size, especially regarding coexistence, calendar synchronization, cutover timing, and mail-routing best practices

Answer 1

Hi Glenn Maxwell

According to my research based on your detailed description, I would like to share some information that I hope it will be helpful:

Calendar synchronization

Disabling the third‑party calendar synchronization tool before starting bulk migration is typically recommended.

• Running both synchronization and migration at the same time can introduce duplicate or looping events.
• Microsoft migration tooling supports calendar migration directly, so using both concurrently can create conflicts.

Microsoft guidance states that calendar data can be migrated as part of the batch migration process alongside mail and contacts:

Perform a Google Workspace migration to Microsoft 365 or Office 365 | Microsoft Learn

Migrate business email and calendar from Google Workspace - Microsoft 365 admin | Microsoft Learn

If calendars are not migrated, a long‑term dependency on the sync solution may be required.

Migration scope (calendar and tasks)

• Calendars: Migrating calendars is generally recommended for long-term consistency in Exchange Online.
• Tasks: Task migration is not part of the standard Google Workspace to Microsoft 365 migration scope, which primarily covers mail, calendar, and contacts.

Your current configuration (Exclude Tasks = Yes) is reasonable.

FastTrack migration behavior

Your understanding of the migration stages is mostly correct. Typical batch migration behavior:

• Initial synchronization: Migrates most mailbox data in the background.
• Incremental (delta) synchronization: Continues to sync new and modified items while both environments remain active.
• Microsoft states that migrations can be performed in batches while both environments remain active, supporting coexistence scenarios. Migrate business email and calendar from Google Workspace - Microsoft 365 admin | Microsoft Learn

User experience during migration

The recommended approach is:

• Users typically continue using Google Workspace during Initial and Delta sync.
• Users switch to Outlook after the Completion Event.

This avoids divergence between systems and reduces data reconciliation issues.

Completion Event

Your understanding is correct, the completion stage typically:

• Performs a final synchronization
• Marks migration complete
• Stops further synchronization

After this step, the Google mailbox is generally no longer treated as the primary system.

Mail flow and coexistence

Your approach using a secure email gateway is a supported scenario.

Microsoft states that organizations may:

• Route mail through third-party email services while using Microsoft 365 mailboxes (Mail flow best practices for Exchange Online, Microsoft 365, and Office 365 (overview) | Microsoft …)
• Implement coexistence models with staged migration and routing adjustments

Here are the factors to note:

• Ensure correct recipient mapping on the gateway
• Avoid routing loops
• Validate mail delivery paths during coexistence

SPF, DKIM, and DMARC

a/ SPF

• SPF should include: Microsoft 365 (include:spf.protection.outlook.com); your email gateway
• Microsoft highlights correct SPF configuration as critical to avoid mail flow issues

b/ DKIM

• Recommended to enable DKIM signing for Microsoft 365 domains
• DKIM is not enabled by default for custom domains in all scenarios and requires configuration

c/ DMARC

No immediate changes are required during cutover. Best practice is to begin with monitoring (p=none) and then gradually enforce policies after migration.

Accepted domains and hybrid routing

For your hybrid Exchange scenario, you will need to configure the domain in Exchange Online as an accepted domain.

Microsoft states:

• Authoritative domain: All recipients are hosted in Microsoft 365
• Internal relay domain: Mail can be routed to external systems (ex:, Google or on‑premises)

Typical migration pattern:

• During coexistence: Internal relay
• After full migration: Authoritative

If using Internal Relay, a connector is required for routing messages to external systems.

Manage accepted domains in Exchange Online | Microsoft Learn

Sending and receiving with the same domain

To continue using the same SMTP domain after migration:

• Add and verify the domain in Microsoft 365
• Configure it as an accepted domain
• Assign SMTP addresses to users
• Ensure routing (connectors / gateway) is aligned

This ensures users can send and receive using the same domain post-migration.

I hope this information helps and if you have any questions, please feel free to ask via comment section.

---

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Answer 2

For this scenario, the supported guidance in the context focuses on the standard Google Workspace → Microsoft 365 migration behavior, coexistence model, and when to cut over users and MX.

Key points aligned with the documented behavior:

1. Use the specialized Google Workspace migration process
   The recommended path is the dedicated Google Workspace migration to Exchange Online rather than a generic IMAP-only migration, because it is designed for staged coexistence and cutover. See: Migrate Google Workspace (formerly G Suite) mailboxes to Microsoft 365 or Office 365 and the backend overview.
2. What gets migrated and what does not
   • IMAP-based migrations only move email, not calendar or contacts. Users must import those separately if IMAP is used: Migrate Google Workspace (formerly G Suite) mailboxes to Microsoft 365 or Office 365.
   • For calendar and contacts, users can import them later using:
     • Import contacts to Outlook
     • Import Google Calendar to Outlook
3. Coexistence and when users should move to Outlook
   The documented staged model for Google Workspace → Microsoft 365 is:
   • While MX still points to Google Workspace, users continue to work primarily in Google Workspace.
   • Mail is synced from Google Workspace into Exchange Online during migration.
   • For migrated users, automatic forwarding is configured in Google Workspace so that new messages are delivered into Microsoft 365 while MX still points to Google Workspace. This requires that users are allowed to set SMTP forwarding in Google Workspace; otherwise forwarding cannot be set: Overview of the G Suite migration process in Exchange Online.
   After all batches are migrated and validated:
   • Users can use their Microsoft 365 mailboxes as their primary mailbox.
   • MX for the primary domain is then manually updated to point to Microsoft 365 instead of Google Workspace.
   • Routing domains and extra aliases used for coexistence can be removed, as can the Google Workspace tenant.
     This is the point at which users should be fully on Outlook/Exchange Online.
4. Behavior of the migration batches and when to delete them
   For IMAP-style migrations via the Microsoft 365 admin center:
   • Batches perform an initial sync and then daily incremental syncs.
   • It is recommended to let a batch run for at least 72 hours before deleting it, so that:
     • Gmail and Microsoft 365 mailboxes have synchronized at least once (they sync once a day).
     • External systems have recognized MX changes and are sending mail to Microsoft 365.
   • After confirming all users are exclusively using Microsoft 365, the batch can be deleted; the migration service then cleans up batch records: Migrate Google Workspace mailboxes to Microsoft 365 or Office 365.
   This aligns with the idea that users can remain on Google Workspace during the sync phase and move to Outlook when cutover (completion) is near, then the batch is removed after a stable period.
5. Mail flow and MX cutover
   The documented end state for the Google Workspace migration is:
   • After all migration batches are complete and users are using Microsoft 365 as their primary mailbox, the MX record for the primary domain is updated to point to Microsoft 365.
   • At that point, routing domains and the Google Workspace tenant can be decommissioned: Overview of the G Suite migration process in Exchange Online.
   The context does not provide specific guidance about intermediate routing through a third‑party secure email gateway, SPF, DKIM, or DMARC changes, so only the general MX cutover behavior above is supported.
6. Performance and batch sizing
   For migrations in this size range, Microsoft recommends planning around migration throughput and using appropriate methods. The performance and best practices article notes that Exchange Online also offers a specialized process in Modern EAC for Gmail/Google Workspace migrations and that IMAP migrations are supported for other systems: Microsoft 365 and Office 365 email migration performance and best practices.
7. Using other migration options if needed
   If the mailboxes contain large amounts of data, the Import service can be used to import PST files instead of or in addition to online migration, and partners or third‑party tools can be engaged when appropriate: Decide on a migration path in Exchange Online.

The context does not cover FastTrack-specific “Initial/Completion Event” terminology, task migration, or detailed SPF/DKIM/DMARC and gateway coexistence design, so only the general migration, coexistence, and MX cutover behavior above is supported.

---

References:

• Migrate Google Workspace mailboxes to Microsoft 365 or Office 365
• Overview of the G Suite migration process in Exchange Online
• Microsoft 365 and Office 365 email migration performance and best practices
• Decide on a migration path in Exchange Online