IT Admins' Playbook: Verify Domains in Google Workspace to

Use Microsoft's automated batch migration through the Exchange admin center for email, calendar, and contacts, and Migration Manager for Drive. Before you touch a single mailbox, verify your domains, create routing subdomains, and provision a migration admin account. Run a small pilot group first. Everything else in this playbook builds on that sequence.

TL;DR:

Automated batch migration is recommended over manual or IMAP methods, especially for organizations requiring calendar and contact transfer alongside email.

Proper preparation, including verifying domains, creating routing subdomains, and testing API quotas, is crucial to prevent mail flow and migration failures.

Conducting a detailed pilot with users from different roles helps identify permission and data transfer issues before full-scale migration.

Shared Drive permissions, Google Chat history, and Vault data often require manual reconciliation after migration, as they don't transfer automatically.

Post-migration, organizations must assign licenses, secure accounts, and carefully manage Google Workspace data deletion to avoid irreversible data loss.

Which migration method fits your environment
Prerequisites and planning before you start
Pilot, batch, cutover: the phased migration sequence
What won't migrate and where admins get tripped up
Post-migration tasks and retiring Google Workspace
When a migration playbook isn't enough
What actually matters in this migration
A path that fits teams without a dedicated migration specialist
Sources
FAQ

Which migration method fits your environment

Microsoft recommends automated batch migration over manual or IMAP methods for moving from Google Workspace, and for good reason. It transfers mail, calendar items, and contacts in groups, keeps both platforms running during the transition, and gives you a dashboard to watch batch status instead of guessing. The migration has a default message size limit which can be configured to allow larger messages, and contact migration supports multiple email addresses per contact within system limits, so flag any user exceeding typical sizes before you start.

IMAP migration is the fallback option, not the first choice. It moves mail only, no calendar, no contacts, which makes it a poor fit for any organization that depends on shared scheduling or synced address books. It still has a place for very small accounts or one-off mailbox cleanups where calendar history does not matter.

Third-party tools cover ground that neither Microsoft option touches well, including Google Groups, Chat history, and Vault archives. They add licensing cost and usually require manual permission mapping on the back end, so budget time for reconciliation rather than expecting a clean handoff.

Your decision checklist should cover:

Scale: how many mailboxes and how much Drive data you're moving.
Data types: whether Groups, Chat, or Vault records need to survive the move.
Downtime tolerance: whether the business can absorb a hard cutover or needs phased coexistence.
Compliance needs: whether retention or legal hold requirements dictate extra handling.

For most small and mid-sized organizations, automated batch migration plus Migration Manager covers the bulk of the work, with a third-party tool brought in only for the data types those platforms don't handle.

Prerequisites and planning before you start

Migration failures usually trace back to skipped prep work, not the migration tool itself. Before scheduling anything, work through this checklist.

Verify domain ownership in Microsoft 365, then create routing subdomains such as m365.example.com and gsuite.example.com so mail routes correctly in both directions during coexistence.
Set up a Google service account with the correct API scopes and assign the Recipient Management role in Exchange to the account running the migration.
Provision mail users and proxy addresses in Microsoft 365 that match every primary address in Google Workspace, and map out license assignments before the first batch runs.
Review retention and archival policies on both platforms and temporarily disable anything that could hide messages during verification, documenting the original settings so you can restore them later.
Test your Google API quota limits with a small sample before committing to a batch size, since calendar and contact migration throughput is throttled by those quotas.

Misconfigured proxy addresses or unverified routing domains are the most common source of mail flow failures after cutover, and resolving them usually means working across both the Microsoft 365 admin center and the Google admin console at once. Our cloud migration checklist walks through the same groundwork in more detail if you want a second pass before scheduling your pilot.

Pilot, batch, cutover: the phased migration sequence

Microsoft's own guidance treats this as a coexistence project, not a weekend cutover, and the sequence matters more than the speed.

Run a pilot. Pick a handful of users across different roles, migrate their email, calendar, and contacts, and confirm Drive transfers work if any of them use Shared Drives.
Build your batches. Import a CSV of users into the Exchange admin center, choose the target delivery domain, and set start and completion options for each group.
Monitor batch status. Watch each migration batch until it shows "Synced" before moving to the next group or attempting to complete it.
Cut over DNS. Update MX records once the final batches are synced, complete the migration, and assign Microsoft 365 licenses to every migrated user.
Reconcile Drive permissions. Resolve any Shared Drive or folder permission mismatches that Migration Manager didn't carry over cleanly.
Validate and ticket. Have each department confirm mail flow, calendar access, and file access, and route any issues through a dedicated ticket queue for the first week.

Pro Tip: Keep both platforms active during the batch phase. Coexistence through routing subdomains gives you a rollback path if a batch fails validation, instead of forcing an all-or-nothing cutover.

Build your internal communications checklist alongside this sequence so users know what's changing and when, rather than finding out when their calendar stops syncing.

What won't migrate and where admins get tripped up

Automated tools cover the core of email, calendar, and contacts well, but several categories need manual attention or simply don't transfer.

Google Chat history generally does not migrate and needs a separate export if retention matters.
Some shared calendar metadata can be lost in translation, so spot-check shared calendars after each batch.
Drive permission patterns and Apps Script behavior often require manual reconciliation once content lands in OneDrive or SharePoint.
Delegated, room, and resource mailboxes need individual verification since they don't always inherit permissions the way standard mailboxes do.

Retention and archive policies on both platforms are a leading cause of what looks like missing mail during verification. Microsoft's migration guidance points to disabling or adjusting these policies until verification is complete, since messages under active retention can simply appear absent rather than actually being lost.

Service account API quotas throttle how fast calendar and contact data move, so plan batch sizes with that ceiling in mind rather than discovering it mid-migration. Vault data needs its own export plan since it sits outside the standard mailbox migration path entirely.

Post-migration tasks and retiring Google Workspace

Once the last batch syncs, the work shifts from moving data to locking down the new environment.

Assign Microsoft 365 licenses to every migrated user and confirm sign-in and mail flow before declaring the migration complete.
Enable MFA and conditional access across all accounts; our MFA setup guide covers the configuration steps.
Reconcile Drive and SharePoint permissions, and archive any Google data that didn't make the migration cut.
Export before you cancel. Google Workspace guidance is explicit that deleting an organization account is irreversible, with user data permanently removed, while canceling the subscription preserves a window to retrieve anything you missed.
Clean up DNS by removing temporary routing subdomains once coexistence is no longer needed.

Treat cancellation as a deliberate step with a retention window, not something you trigger the same day the last batch completes.

When a migration playbook isn't enough

Our own migration playbook follows this same sequence: planning, pilot, phased batches, validation, and security hardening, documented in detail in our practical IT admin playbook. It mirrors what Microsoft documents because the sequence works, but most internal IT teams are running this migration on top of their regular ticket queue, not instead of it.

A few signals suggest that it's time to bring in a managed partner:

Limited admin bandwidth to run a multi-week phased migration alongside daily support tickets.
Complex Drive, Groups, or Vault data that needs manual reconciliation beyond what the standard tools handle.
Compliance obligations that require documented evidence of each migration step.

Pro Tip: A fixed-cost migration engagement with 24/7 monitoring during cutover removes the single biggest risk factor: nobody watching the batch queue at 11 p.m. when a sync fails.

What actually matters in this migration

Most migration guides treat the technical steps as the hard part. They aren't. Microsoft's tooling is mature, well documented, and handles the mechanics of batch migration reliably when the prerequisites are done right. The part teams underestimate is the human side: communicating the cutover date clearly, training users on where their files actually live afterward, and having someone watch the batch queue during the cutover window instead of assuming it will finish cleanly overnight.

The conventional advice focuses heavily on picking the right migration tool. That choice matters less than most guides suggest, since automated batch migration is the right default for nearly every organization moving from Google Workspace. What determines whether the project goes smoothly is the prep work nobody wants to do: domain verification, proxy address mapping, and a retention policy review that gets skipped under deadline pressure.

If you take one thing from this, prioritize the pilot. A rushed pilot with two users tells you nothing. A real pilot, covering different roles and data types, surfaces the permission and Apps Script problems before they hit three hundred mailboxes at once.

, Dustin Collett

A path that fits teams without a dedicated migration specialist

Running this migration well takes a team that can watch batch status at odd hours and troubleshoot a failed sync without waiting until Monday. Managed IT support with fixed per-user pricing and 24/7 monitoring can help ensure a migration cutover doesn't depend on one admin staying up late. If your current IT setup already stretches thin on routine support, a migration adds real risk on top of that. Our Managed IT Services cover the planning, pilot, and cutover phases as part of the standard stack, not as a separate add-on project. For teams tackling complex data mapping, a partner like Ampwise AI can help automate parts of the email and system integration work alongside the core migration.

Start with our IT & Security Assessment to get a clear picture of what your environment needs before you schedule a single batch.

Sources

FAQ

How do I transfer Google Workspace to Microsoft 365?

Verify your domains, create routing subdomains, and provision mail users in Microsoft 365, then run automated batch migration through the Exchange admin center for email, calendar, and contacts. Use Migration Manager separately for Drive content, and always test with a small pilot group before running full batches.

Can Google Workspace work with Microsoft 365?

Yes, the two platforms can run side by side during a phased migration through routing subdomains that direct mail to the correct system. This coexistence period lets you migrate users in batches rather than forcing a single hard cutover.

Will I lose my emails if I cancel Google Workspace?

Canceling a subscription preserves a window to retrieve data, but deleting the organization account is irreversible and permanently removes user data. Export everything you need before initiating cancellation or deletion, and don't treat the two actions as interchangeable.

Should I use Microsoft 365 or Google Workspace?

The right platform depends on your existing tools, compliance needs, and team habits rather than a universal answer. Organizations already standardized on Microsoft 365 for collaboration or compliance documentation often find the migration itself is the bigger decision than the platform choice.

IT Admins' Playbook: Verify Domains in Google Workspace to M365

Table of Contents