GOOGLE WORKSPACE TO MICROSOFT 365 MIGRATION

A Deep-Dive Step-by-Step Technical Guide – end-to-end Google Workspace to Microsoft 365 migration process

Introduction

Migrating from Google Workspace to Microsoft 365 is a common scenario for organizations aiming to leverage Microsoft’s integrated productivity and security ecosystem. This guide focuses on performing migration using the built-in Google Workspace migration feature in Exchange Online (EXO). It provides a complete, real-world deep dive—from prerequisites to post-migration validation.

Phase 1: Google Workspace – Pre-Migration Setup

Before initiating any migration, it’s critical to prepare the source environment (Google Workspace) properly.

Step 1: Ensure Super Admin Access in Google Workspace

To begin the migration, you must have a Super Administrator account in Google Workspace. This is essential because you’ll need to create and authorize a Google Cloud project, enable APIs, and grant domain-wide delegation permissions—tasks only possible with Super Admin rights.

Step 2: Log In to the Google Cloud Admin Console

⚠️ Note: Do not use the regular Google Workspace admin portal (admin.google.com). Instead, access the Google Cloud Console at console.cloud.google.com, which is required to set up the service account and enable API scopes.

Step 3: Create a Google Cloud Project for Migration

After logging into the Google Cloud Console, the next step is to create a dedicated project that will be used specifically for the migration process. This project acts as a container to manage all the APIs, credentials, and permissions needed.

How to create the project:

1. In the Google Cloud Console (console.cloud.google.com), click the Project Selector dropdown near the top-left corner.
2. Click New Project.
3. Enter a name for your project. For clarity, you can name it something like:
   • M365-Migration
   • GoogleToMicrosoft365-Migration
   • Or any descriptive name relevant to your organization.
4. Select the Organization if applicable.
5. Click Create.

Once created, this project will be the workspace where you enable the required APIs and create service accounts for migration.

Step 4: Enable Required APIs in Google Cloud Project

Once your Google Cloud project is created, you need to enable several APIs that allow Microsoft 365 to access the necessary Google Workspace data for migration.

Important APIs to enable include:

• Gmail API – To access users’ emails.
• Admin SDK – To read user and domain information.
• People API – To migrate contacts.
• Calendar API – To migrate calendar events.
• Drive API – If you plan to migrate Google Drive data (optional, based on scope).

How to enable APIs:

1. In the Google Cloud Console, select your migration project.
2. Navigate to APIs & Services > Library from the left-hand menu.
3. In the search bar, type each API name one by one (e.g., “Gmail API”).
4. Click the API from the search results, then click Enable.
5. Repeat for all required APIs (Gmail API, Admin SDK, People API, Calendar API, Drive API).

Step 5: Create a Service Account and Assign Permissions

Now that your APIs are enabled, the next step is to create a Service Account. This account acts as a bridge between Google Workspace and Microsoft 365 during the migration process.

The service account must have Owner permissions within the project so it can access and manage the APIs you’ve enabled.

How to Create a Service Account:

1. In the Google Cloud Console, navigate to IAM & Admin > Service Accounts from the left-hand menu.
2. Click + CREATE SERVICE ACCOUNT at the top.
3. Enter a name such as m365-migration-service.
4. Optionally, provide a description (e.g., “Service account for Google to Microsoft 365 email migration”).
5. Click Create and Continue.

Assign Project-Level Permissions

1. On the next screen, under Grant this service account access to the project, select:
   • Role: Owner
2. Click Continue, then Done.

 Note: Granting the “Owner” role gives the account full access to manage resources in the project. This is acceptable in a temporary project created just for migration, but for production environments, consider using the principle of least privilege.

Step 6: Disable the Organization Policy Restricting Service Account Key Creation (if enforced)

In some Google Workspace environments, there’s an organization policy that blocks the creation of service account keys. If this policy is enabled, you will see an error when trying to generate a JSON key for your service account.

❗ Common Error Message:
“The organization policy constraint constraints/iam.disableServiceAccountKeyCreation is enforced and prevents service account key creation.”

Solution: Disable the Policy iam.disableServiceAccountKeyCreation

To create the key successfully, you must first disable this constraint in the organization policy.

Required Role: Organization Policy Administrator

To make this change, your account must have the Organization Policy Administrator role.

How to Assign “Organization Policy Administrator” Role

1. Go to IAM & Admin > IAM.

1. Locate the user account you’re using for migration.

1. Click the Edit icon (pencil) next to the user.
2. Click Add Another Role.

1. Search for and add:
   • Organization Policy Administrator

1. Click Save.

How to Disable the Policy:

Navigate to IAM & Admin > Organization Policies.

Click on the policy named:

If it shows “Enforced”, click Edit.

Choose “Not enforced”, then save.

Step 7: Create JSON Key and Configure Domain-Wide Delegation

With the organization policy unlocked, you can now generate the JSON key for your service account and configure it for domain-wide delegation, allowing Microsoft 365 to impersonate Google Workspace users during migration.

Create the Service Account Key (JSON)

1. In the Google Cloud Console, go to IAM & Admin > Service Accounts.

1. Click on the service account you created earlier (e.g., m365-migration-service).

1. Go to the Keys tab.
2. Click Add Key > Create new key.

1. Choose JSON format.
2. Click Create — the key file will be automatically downloaded to your local machine.

Important: Store this JSON key securely. You’ll use it in the Microsoft 365 Admin Center or via PowerShell to authenticate the migration process.

Step 8: Enable Google Workspace Marketplace OAuth Client Setting

Why this is needed:
Enabling the Marketplace OAuth Client setting allows the service account to be used as an authorized identity to access user data via domain-wide delegation.

How to enable:

1. Still in the Service Account page, go to the Details tab.

1. Click Show Advanced Settings.

1. Toggle on the option for:
   • “Enable Google Workspace Marketplace SDK”
   • Then Enable OAuth Scopes / Domain-Wide Delegation

Step 9: Delegate Domain-Wide Authority to the Service Account

Now that your service account is ready and the key is generated, you must delegate domain-wide access through the Google Admin Console.

  Sign in to https://admin.google.com using a Super Administrator account.

1. Scroll down to Security  – > API Controls -> Domain-wide delegation, and click Manage Domain Wide Delegation.

Click Add New.

 Provide the following details:

• Client ID:
  • Go back to your service account in Google Cloud Console, and copy the Client ID from the “Details” tab.

• OAuth Scopes (comma-separated list):
  • These define what kind of data the service account is allowed to access.
  • Recommended scopes for typical migration:

• https://mail.google.com/,
• https://www.googleapis.com/auth/gmail.readonly,
• https://www.googleapis.com/auth/admin.directory.user.readonly,
• https://www.googleapis.com/auth/calendar.readonly,
• https://www.googleapis.com/auth/contacts.readonly,
• https://www.googleapis.com/auth/drive.readonly

1. Click Authorize.

What Does:

By completing domain-wide delegation, you authorize the service account to impersonate users in your domain and access their Gmail, Calendar, Contacts, and Drive data. This is what makes seamless user data migration to Microsoft 365 possible.

Phase 2 : Microsoft 365 – Pre-Migration Setup

Step 1: Prepare Microsoft 365 – Add and Verify Your Google Domain

To migrate mailboxes from Google Workspace to Microsoft 365, you must first add your organization’s domain (the one currently used in Google, like your domain.com) to your Microsoft 365 tenant. This ensures that Microsoft 365 recognizes the domain and allows user accounts to be created or matched.

Steps to Add and Verify Your Domain:

1. Sign in to the Microsoft 365 Admin Center:
   https://admin.microsoft.com
2. Go to Settings > Domains, then click + Add domain.
3. Enter the domain you used in Google Workspace (e.g., yourdomain.com) and click Next.
4. Microsoft will prompt you to verify ownership by adding a TXT record in your DNS provider (this is usually Google Domains, Cloudflare, or your domain registrar).
5. After the TXT record is added, go back to Microsoft 365 and click Verify.

Step 2: Create Users and Assign Licenses in Microsoft 365

Once the domain is verified, you can begin preparing users who will be part of the migration.

Options:

• Manual User Creation – Add users one by one via the Microsoft 365 Admin Center.
• CSV Bulk Import – Upload a list of users if you’re migrating a large organization.
• Azure AD Connect or Directory Sync – If you’re syncing from an on-premises Active Directory.

For each user:

• Make sure the email address matches the one in Google Workspace (i.e., user@yourdomain.com).
• Assign a Microsoft 365 license that includes Exchange Online (e.g., Microsoft 365 Business Standard or E3/E5).
• Ensure their mailbox is provisioned (Microsoft auto-provisions after licensing).

Step 3: Configure Subdomains for Coexistence and Mail Flow Management

In some migration scenarios — especially staged migrations or when you want mail flow continuity between Google and Microsoft 365 — it’s best practice to set up subdomains on both sides. This setup helps route mail properly and avoid delivery failures while users are split across the two platforms.

Why Subdomains Are Needed

Subdomains help manage email routing and coexistence in scenarios where:

• You’re migrating users in phases (some users remain on Google while others move to M365).
• You want to test mail flow or mailbox setup in Microsoft 365 before fully cutting over.
• You need to maintain split delivery or dual delivery
• You’re performing a pilot migration before the full move.

 You don’t need subdomains if you’re doing a full cutover migration (all users moved at once, and the domain’s MX records are switched completely to Microsoft 365 at the end).

Subdomain Setup – Google Workspace Side

Let’s say your main domain is domain.com.

You create a subdomain like:
gsuite.domain.com for use within Google Workspace.

Steps:

1. In your DNS provider (like Google Domains or Cloudflare), add the subdomain:
2. TXT record for domain verification in Google.
3. Go to Google Admin Console > Domains > Manage Domains, then click Add a domain or alias. (Add it as an Alias Domain if you want users in Google to receive emails addressed to both user@domain.com and user@gsuite.domain.com.)
4. Add gsuite.domain.com as a secondary domain, not an alias.
5. Verify using the TXT record.
6. Add MX Records for Google Side – Only set the MX records for gsuite.domain.com pointing to Google’s mail servers
7. Important: Do not change the MX records for your root domain yet (com).

Subdomain Setup – Microsoft 365 Side

Now, for Microsoft 365, create a matching subdomain like:
m365.domain.com

Steps:

1. Go to Microsoft 365 Admin Center > Settings > Domains, then click Add domain.
2. Enter m365.domain.com and click Next.
3. Since the primary domain domain.com is already verified, Microsoft 365 will automatically verify the subdomain using inherited TXT records — no need to add a new TXT.
4. Add MX Records for M365 Side – Only set the MX records for m365.domain.com pointing to Microsoft 365

Why This Works

With this setup:

• Mail for users still on Google continues to flow via gsuite.domain.com.
• Mail for users already migrated goes through m365.domain.com.
• You can configure routing rules (or connectors) on both platforms to forward mail to the correct destination based on the user’s location.

This method prevents mail loops, delivery failures, and confusion during the transition period.

Step 4 : Add Subdomains as Alias Domains and Configure Proxy SMTP Addresses

In addition to adding subdomains for coexistence and routing, you need to assign them as alias domains to ensure proper delivery when emails are sent or forwarded using alternate addresses.

Phase 3  Create a Migration Endpoint in Exchange Online (EXO)

The Migration Endpoint is the connection configuration Microsoft 365 uses to securely access and extract data from Google Workspace mailboxes. This endpoint leverages the JSON key, service account, and OAuth scopes you’ve previously set up.

Prerequisites:

Before you create the endpoint, make sure you have:

• The JSON key file downloaded from Google Cloud Console.
• Domain-wide delegation set up and authorized in Google Admin Console.
• Users created and licensed in Microsoft 365.
• PowerShell ready (for advanced scenarios) or access to Microsoft 365 Admin Center.

Step 1 Create Migration Endpoint via Microsoft 365 Admin Center

1. Go to the Microsoft 365 Admin Center → Exchange Admin Center:
   https://admin.exchange.microsoft.com
2. Navigate to:
   Migration > Migration Endpoints
3. Click + Add migration endpoint.

4. Choose Google Workspace (Gmail) as the migration type.
5. Upload your service account JSON key file.
6. Enter the required details:
7. Email Address for Test – A test user from Google Workspace (e.g., user1@domain.com) to validate access.
8. Click Next and validate the connection.
9. Give the endpoint a name (e.g., Google-MigrationEndpoint) and click Save.

Step 2 : Create and Manage Migration Batches in Microsoft 365 (Exchange Admin Center)

Now that the migration endpoint is set up and alias subdomains are configured, you’re ready to begin migrating users from Google Workspace to Microsoft 365.

This is done by creating migration batches, which are groups of users that will be migrated together. You can do this using the Exchange Admin Center (GUI) or via PowerShell.

Create Migration Batches via Exchange Admin Center (EAC)

1. Go to:
   https://admin.exchange.microsoft.com
2. Navigate to:
   Migration > Batch
3. Click + Add migration batch.
4. Choose Google Workspace (Gmail) as the migration type.
5. Upload a CSV file with the users you want to migrate.
6. Select the migration endpoint you created earlier.
7. Name the batch (e.g., Batch-GoogleWave1).
8. Configure options:
9. Choose to start manually or automatically.
10. Select a recipient for migration notifications.
11. Auto-complete or manually finalize the batch later.

Monitoring the Batch

After creating the batch:

• Go to Migration > Batch to track its status.
• You’ll see details like:
  • Total users
  • Synced users
  • Errors or failures
  • Sync percentage
• You can restart, complete, or delete the batch from here.

Finalizing the Migration

Once you confirm mail has synced and users are active in Microsoft 365:

• Use Complete-MigrationBatch to finalize:

Then, switch the MX records of your root domain (domain.com) to Microsoft 365 mail servers.

Enable Throttling Override in Microsoft 365 to Improve Migration Speed

To prevent performance issues during large migrations, Microsoft throttles workloads like mailbox moves. However, for planned and approved migrations (like Google to Microsoft 365), you can temporarily bypass these throttling limits using Service Request-based throttling override.

Why Enable Throttling Override?

1. Increases concurrent mailbox moves
2. Reduces delays in mailbox sync
3. Ideal for bulk migrations or tight migration timelines

Post-Migration Checklist

1. MX switched
2.  Test mail flow (inbound/outbound)
3. Outlook profile recreated (via Autodiscover)
4.  Mobile devices reconfigured
5.  Remove aliases from Google if needed
6. Turn off Google MX (after 48–72 hours buffer)

Migration Limitations Matrix

Conclusion & Final Thoughts

Migrating from Google Workspace to Microsoft 365 using Google Workspace Migration in Exchange Online (EXO) is a powerful and structured process — but one that requires careful planning, the right permissions, and an understanding of both platforms’ differences.

In this guide, I have covered:

• Preparing your Google environment (APIs, service accounts, delegation)
• Setting up Microsoft 365 (domain verification, licensing, aliasing)
•  Mail flow coexistence via subdomain configuration
•  Batch migration setup and performance tuning (e.g., throttling override)
•  Limitations and data types that don’t migrate (Drive files, Chat, Filters, etc.)

Next Steps After Migration

•  Verify full mail delivery post-cutover
•  Reconfigure Outlook profiles and mobile email clients
• Rebuild any shared calendars, permissions, or groups as needed
• Review Microsoft Purview compliance, retention, and eDiscovery setup
•  Decommission legacy services (Google Vault, Drive, Groups) if no longer needed