Migrating Google Workspace to Microsoft 365 Without Losing Mail

Moving a company from Google Workspace to Microsoft 365 is a different job from an Exchange migration. There is no hybrid, no shared directory, and the data lives in labels, Drive shares and Google-format documents rather than in mailboxes and file servers. The native Microsoft tools handle most of it now, but the order of operations matters.

This post covers the mail, calendar and contacts move through the Exchange admin center, the Drive move through Migration Manager, and the coexistence setup that keeps mail flowing while you work.

Set up the Google side first

Microsoft's Google Workspace migration reads data through Google APIs using a service account with domain-wide delegation. The service account signs in as each user without needing their password. Setting this up is the part most people get wrong.

In the Google Cloud console, create a project, enable the Gmail, Google Calendar, People (Contacts) and Google Drive APIs, create a service account, and download a JSON key. Note the client ID of the service account. Then in the Google Admin console under Security, API controls, Domain-wide delegation, add that client ID with the read scopes for mail, calendar, contacts and drive.

• https://mail.google.com/
• https://www.googleapis.com/auth/calendar
• https://www.googleapis.com/auth/contacts
• https://www.googleapis.com/auth/gmail.settings.sharing

Prepare the tenant and coexistence routing

Create the users in Microsoft 365 with licenses assigned before you migrate. The tool needs a target mailbox to write into. Keep the same primary addresses as in Google.

Mail will keep arriving at Google until you switch MX. To let migrated users receive mail in the meantime, the wizard uses a routing subdomain. Add a subdomain such as m365.domain.com in Google Workspace as a domain alias with its MX pointed at Microsoft 365, and verify that subdomain in the tenant. When a mailbox finishes migrating, Google forwards new mail for that user to user@m365.domain.com, and Microsoft 365 delivers it to the real mailbox. Users on either side keep sending to the normal address.

For the endpoint, upload the JSON key and give the email address of a Google super admin.

New-MigrationEndpoint -Gmail -ServiceAccountKeyFileData ([System.IO.File]::ReadAllBytes("C:\migration\gkey.json")) -EmailAddress admin@domain.com -Name GoogleEndpoint
New-MigrationBatch -Name GoogleBatch1 -SourceEndpoint GoogleEndpoint -CSVData ([System.IO.File]::ReadAllBytes("C:\migration\batch1.csv")) -TargetDeliveryDomain m365.domain.com -AutoStart

What migrates and what does not

The Exchange admin center batch moves mail, calendar and contacts. Labels become folders. A message with three labels ends up as one message in one folder with the others represented as Outlook categories, so tell users to expect their labeling to flatten. Gmail's All Mail archive lands in a folder rather than disappearing. Calendar events and their attendees move, and recurring meetings usually survive, but shared calendars have to be re-shared after the move.

Google Drive is a separate tool. Migration Manager in the SharePoint admin center connects to Google with a similar delegated app, scans every user's Drive and shared drives, and lets you map each source to a OneDrive or a SharePoint document library. Google Docs, Sheets and Slides are converted to Word, Excel and PowerPoint formats on the way, which works for most files but breaks Apps Script and some complex formulas. Google Forms and Sites do not move.

Chat history, Groups, and Vault archives also do not migrate natively. Export what you must keep.

• Mail, calendar, contacts: Exchange admin center Google Workspace migration.
• My Drive and shared drives: SharePoint admin center Migration Manager, Google source.
• Google Groups: recreate as distribution lists or Microsoft 365 Groups.
• Chat, Forms, Sites, Vault: export or leave in Google for a read-only period.

Order of operations

The migration runs in two passes per batch: an initial copy while the user is still working in Gmail, then a final incremental sync when you complete the batch. That means you can start copying weeks before cutover. Google throttles per user, so a large mailbox may take days for the first pass.

A workable sequence for a company of any size looks like this.

1. Verify the domain and the routing subdomain in Microsoft 365. Create and license users.
2. Create the Google Cloud project, service account and delegation. Create the endpoint and test it with one user.
3. Start the mail batches for all users so the bulk of data copies early.
4. Start Drive migrations in Migration Manager with a scan first, then fix files that fail the scan.
5. Pick the cutover day. Complete the mail batches that morning so the final sync runs, then switch MX and Autodiscover to Microsoft 365.
6. Keep Google licenses for two to four weeks as a read-only fallback, then export Vault and cancel.

The user-facing part

The technical move is the easy half. Users who lived in Gmail for years have muscle memory for its search and shortcuts. Outlook on the web is the closest experience, so start people there rather than dropping them straight into desktop Outlook. Explain that labels are now folders and categories.

Mobile devices are a clean break. Remove the Gmail account from the phone, install Outlook, sign in. If you use Google Authenticator for MFA today, plan the switch to Microsoft Authenticator on the same day so nobody ends up locked out with two authenticator apps.

Frequently asked questions

Takeaway

The tooling is native now, but a Google to Microsoft 365 move still hinges on the service account delegation, the routing subdomain, and starting the bulk copy early. Do those three right and cutover day is a DNS change and a round of phone re-enrollments. If your team would rather not learn two admin consoles for one project, RackLedge runs these migrations end to end.