Migrate Google Workspace to Microsoft 365 with ShareGate: step by step

TL;DR: ShareGate migrates Gmail, Google Calendar, Drive, and contacts to Microsoft 365 from one tool. You get automated user mapping and incremental copy for staged cutovers. Connect Google Workspace as a Super Admin, migrate by workload, then verify.

You're comparing tools to migrate Google Workspace to Microsoft 365 with ShareGate on the shortlist. Makes sense. Your environment is probably a mess right now. Teams tripping over each other in a mixed Google-and-Microsoft setup. Maybe M&A just dropped a Gmail tenant in your lap, and leadership wants everyone on Microsoft 365 by Q3. You need to pick a tool fast. But first, you want to see how the migration actually runs.

This guide shows you the click-by-click: Gmail, Calendar, Drive, contacts, and permissions. Still figuring out what to move and where it lands? Start with what to consider for your Google Workspace to Microsoft 365 migration. If you've already scoped the project and you're ready to evaluate the workflow, keep reading.

The native Microsoft route splits the job across multiple tools. Mail, calendar, and contacts move through the Exchange admin center (or PowerShell). Drive moves through Migration Manager. ShareGate runs all of it from one place. You connect once, map users, and run incremental copies until cutover. Let's walk through it.

Step 1: Before you start (scope it with the pillar first)

Preparation work separates rough migrations from clean ones. Before you touch ShareGate, confirm your Microsoft 365 destination is ready to receive mail and content.

Quick prerequisites check

Your Microsoft 365 domain must be verified with the correct TXT records in place. If you haven't done this yet, you're not ready to migrate mailboxes. This is a native Microsoft requirement, not a ShareGate thing.

Also confirm your tenant has the licenses and storage for incoming users. ShareGate doesn't cap data, but Microsoft 365 does enforce quotas per mailbox and OneDrive account.

Confirm users are provisioned

Every Google Workspace user you're migrating needs a corresponding mail-enabled user in Microsoft 365. You can create these manually, sync from Entra ID, or use ShareGate's Entra ID identity migration (in preview) to copy user identities directly from one tenant to another. Identity mismatches cause downstream failures. Get this right before you start copying mail.

For full scoping guidance, read what to consider for your Google Workspace to Microsoft 365 migration. If you're still evaluating whether Microsoft 365 is the right move, see why organizations move from Google to Microsoft. Microsoft also publishes Microsoft's native Google Workspace mailbox migration guide, and Migration Manager for Google Workspace covers the native Drive path. We're not here to hide it.

One more thing: ShareGate Migrate now gives you cross-source visibility across supported workloads, including Google Workspace. You can run source discovery inside ShareGate instead of toggling between the Google Admin Console and separate tools. Less tab-switching, more context in one place.

Step 2: Migrate mail, calendar, contacts, and Drive with ShareGate

This is the core of your Google Workspace to Microsoft 365 migration. ShareGate Migrate handles Gmail, Google Calendar, Drive, and contacts in one tool. Permissions, structure, and metadata come along for the ride.

No per-user consent prompts. No juggling separate wizards. Just connect once and get to work.

Connect Google Workspace

In ShareGate, you'll connect Google Workspace as a Super Admin with scoped OAuth permissions using domain-wide delegation. This gives ShareGate access to user data across the tenant without prompting each individual user. Once connected, you can save the connection for future migrations.

Then connect your Microsoft 365 tenant using a Global Admin account. You'll need both connections to map source users to destination recipients.

Run the migration by workload

For Google Drive to OneDrive migration: Go to Copy > Import external content > Import from Google Drive. Pick the target SharePoint site or OneDrive library, select the Drive to migrate, and run. Permissions and folder structure land intact.

For Gmail to Microsoft 365 migration: Go to Copy > Copy mailboxes > Copy from Gmail. Connect Google Workspace as Super Admin (if you haven't already), select the mailboxes and calendars to migrate, connect your Microsoft 365 tenant, and map users to recipients. Adjust copy options and run.

ShareGate's user and recipient mapping screen shows source and destination users side by side. You can auto-match by email or UPN, override matches manually, and save mapping decisions across sessions.

Incremental copy is your friend. ShareGate moves only what's new or changed. This is ideal for staged cutovers. You run an initial migration, let users keep working in Google Workspace, then run a final delta copy right before cutover. No re-processing everything from scratch.

For the full walkthrough on moving from Gmail, read how to migrate from Gmail to Microsoft 365. And for the feature announcement, check out Gmail and Google Calendar migration in ShareGate.

What doesn't migrate cleanly? Some things bump into native Microsoft limits. Room bookings don't migrate. Shared calendars and event colors don't migrate. You can migrate a max of 3 email addresses per contact. Default single-message size caps at 35 MB. Rules migrate but stay off by default. This isn't a ShareGate limitation; it's how Exchange Online works. For the full what-moves/what-doesn't table, see our full Google Workspace to Microsoft 365 migration guide and Microsoft's documentation.

Step 3: Monitor progress and fix errors

Migrations break. Files get stuck. Permissions don't map. This is reality. The trick is catching problems early and re-running only what failed.

In ShareGate, track progress via Tasks in the sidebar. You'll see item-level status: successful, copying, error, skipped. Each item shows what happened and why. Common issues include missing permissions on the source, path length limits, and unsupported file types.

When something fails, you don't start over. Use incremental copy from the Copy screen to re-process only items that errored or skipped. Run it again. Check the report. Repeat until clean. Nobody enjoys re-migrating an entire tenant because one folder had a weird character in the name.

You can export migration reports to share with stakeholders or keep for your records. These reports show what moved, what didn't, and why. Handy for post-migration reviews and CYA documentation.

Step 4: Verify accuracy and cut over

Moving data is half the job. Making sure the right people can access the right stuff is the other half. Broken permissions cause more support tickets than missing files.

Verify content and permissions

ShareGate's Permissions Matrix Report shows who has access to what after migration. You can spot broken inheritance, orphaned permissions, and users who lost access during the move. Run the report across migrated sites and libraries.

Manual spot-checks matter too. Pick a handful of users from different departments. Ask them to verify their OneDrive content, calendar events, and mail. Nothing beats a real human clicking through their own stuff.

Cut over DNS

Once you're confident the migration is complete and verified, update DNS records to point your domain to Microsoft 365. Change the MX records. After you connect the domain to Microsoft 365, mail starts flowing to Exchange Online and all Microsoft 365 services work.

For the full DNS cutover process, see switch from Google Workspace overview on Microsoft Learn.

Step 5: Support end users after the move

Data in place. Permissions verified. DNS flipped. You're not done. Migration changes how people work. They've been in Gmail and Google Drive for years. Now it's Outlook and OneDrive.

Give users quick-reference guides. Hold short training sessions. Set up a dedicated Teams channel or email alias for migration questions. The goal is landing ready to work, not fielding a week of "where's my calendar?" tickets.

User adoption isn't an afterthought. It's how you measure migration success. Nobody wins if the data moved but people can't find it.

Step 6: Clean up and stay Copilot-ready with ShareGate Protect

ShareGate Migrate does migration. Verification and structural cleanup. That's its job. What it doesn't do: ongoing governance, backup, sync, or compliance enforcement.

Once you've moved to Microsoft 365, the next challenge is keeping it secure. Oversharing risks. Stale permissions. Content sprawl. If you're planning to roll out Microsoft 365 Copilot, these problems become urgent. Copilot surfaces what users have access to. If permissions are a mess, Copilot shows them the mess.

That's where ShareGate Protect comes in. It's a separate product built for ongoing governance: identifying overshared content, fixing permissions at scale, and keeping your environment clean long after migration ends.

We're not going to pretend Migrate does governance. It doesn't. But Protect does. For more on the post-migration handoff, see our Gmail migration guide.

Get started with your Google Workspace migration

Now you've seen exactly how ShareGate runs a Google Workspace migration. You know what moves, what doesn't, and how to handle the gaps. The question isn't whether the tool works. It's whether it works for your environment.

Mixed environments cause friction. M&A consolidation doesn't wait. The longer you sit on the decision, the more tickets pile up and the louder stakeholders get.

Book a ShareGate demo and walk through your specific scenario with our team. Want to try it yourself? Start a free trial and run a test migration. Or explore the Google Workspace migration solution page for the full picture.

Don't just migrate it. ShareGate it.