Can we move everyone in one weekend instead of in batches?

You can, and small companies often do. The routing subdomains still earn their place: they are what keeps mail flowing if one batch fails verification and a few people have to stay on the old system for another day. Set them up even for a single-weekend plan.

Do Gmail labels become Outlook folders?

Mail moves with the mailbox, but the label model and the folder model are not the same thing, and categories in Outlook do not line up with Gmail labels. Expect to explain the difference to people on day one rather than to recreate every label.

What happens to files shared with people outside the company?

External sharing links are not recreated by Migration Manager, so those links stop working once people are using the Microsoft copies. Make a list of externally shared folders before the run and reissue the links from SharePoint or OneDrive afterwards.

Google Workspace to Microsoft 365 migration: the checklist

The Monday when nobody could reply

Say a 40-person distributor is bought by a group that already runs Microsoft 365, and the instruction comes down from the parent company: everyone on Exchange Online by the end of the quarter. The mail import runs over a weekend, and on Monday morning the inboxes look right. Then the calls start. The filters that sorted supplier invoices into folders are all switched off. The shared calendar the warehouse used for delivery slots is not there. Two people in sales are still answering from the old system and nobody can tell which messages landed where.

Nothing crashed. Every one of those things is listed in Microsoft's own documentation as not migrated or not enabled, and nobody read that list before the batch ran. Migrations go wrong in the gap between what the tool moves and what the business actually uses. So on this route we write down two things before anything moves: the order of operations, and the list of what a person will have to rebuild by hand. We run migrations in both directions and we stay out of the argument about which suite is better. This is the Google Workspace to Microsoft 365 direction, with Google's and Microsoft's own tools.

Two tools, two admin centers

Mail, calendars, contacts and rules move through the Google migration built into the Exchange admin center. Microsoft documents two ways to run it. The automated batch method is the one Microsoft recommends, because it creates the Google project, the service account and the key for you and switches on the Gmail, Calendar and Contacts APIs. The manual method leaves those steps to you in the Google Admin console. The migration is not available in GCC High or DoD tenants.

Files are a separate job in a separate place. Google Drive, including shared drives, moves into OneDrive and SharePoint through Migration Manager, which you run from the Microsoft 365 admin center after installing the Microsoft 365 migration app from the Google Workspace Marketplace. Both tools come with the licences you already pay for, so a third-party product is worth paying for only when a project genuinely needs something they do not do.

What neither tool moves: groups, delegation, room and resource calendars, and automatic replies. Plan those as work, not as an afterthought.

Before anything moves: users, licences and the two routing subdomains

This is the part that decides whether the cutover is boring. Four things have to be true before the first batch.

Permissions on both sides. On the Microsoft side, the Recipient Management role. On the Google side, an administrator who can create a project and a service account, so the migration can read Gmail, Calendar and Contacts.
People already exist in Microsoft 365. Each user has to be provisioned as a mail user before the batch runs, with an external address on the Google routing subdomain and a proxy address on the Microsoft routing subdomain. The tool migrates data, it does not create accounts or assign licences.
Two routing subdomains, each with its own MX. One routes mail to Microsoft 365, one routes mail back to Google Workspace, so the half of the company that has moved and the half that has not can still answer each other. Microsoft advises using a subdomain of your primary domain, because it verifies automatically, and advises against the built-in onmicrosoft.com domain. An unverified routing domain stops the migration completing. On the Google side the setting can take up to 24 hours to reach every user, so do it a day early.
A message size limit that fits your mail. The largest single message the migration moves follows your tenant transport configuration, and the default is 35 MB. Microsoft's own guide says that default can be raised as far as 150 MB. Anything over the limit stays behind, which is how a company loses exactly the attachments that mattered. Microsoft also recommends turning retention and archive policies off while the migration runs, so moved messages do not look missing when you check counts.

The two routing subdomains are ordinary DNS records. The Microsoft side takes the value your admin center gives you for the domain:

; routes mail to Microsoft 365 during the migration
m365.example.com.   3600   IN   MX   0   example-com.mail.protection.outlook.com.

; routes mail back to Google Workspace for users not moved yet
gws.example.com.    3600   IN   MX   1   smtp.google.com.

Mail, calendar and contacts: what arrives and what does not

This is the table we put in front of a client before anyone schedules a batch. It is usually the moment somebody says "wait, the shared calendar?".

What you have in Google Workspace	What Microsoft 365 does with it	What to do about it
Mail in a user's mailbox	Migrated in batches with the mailbox	Raise the transport limit above the 35 MB default first, or large messages stay behind
Gmail filters	Migrated as rules, but they arrive turned off	Tell people to re-enable their own rules on day one, and review any rule that forwards outside the company
Vacation and automatic reply settings	Not migrated	Re-enter them in Outlook, starting with role addresses like sales and support
Personal calendars, recurring events included	Migrated with the mailbox	Shared calendars, room bookings and event colours are not migrated. Rebuild the shared ones from a list you make before the cutover
Contacts	Migrated with up to three email addresses each	Export contacts that carry more than three addresses, so the extras exist somewhere
Google Groups	No vendor migration path	Recreate them as distribution groups or shared mailboxes and add membership in bulk, before the MX change

Drive and shared drives through Migration Manager

The file side converts as it copies. Docs, Sheets and Slides are exported to .docx, .xlsx and .pptx, and the originals in Drive are left as they are. Drawings arrive as PNG files by default. Forms are migrated, but only when the task has a Forms destination set, which is easy to miss. Google Sites and Google Maps content are not migrated at all, shortcuts are skipped, and files with no owner in your organisation are not scanned, not migrated and not listed in the report.

Three limits cause most of the failed items. The destination path, including the file name, has to come in under 400 characters, so a deep folder tree that passed the scan can still fail on the way in. The maximum file size is 250 GB. And unsupported items do not stop a task from finishing: Migration Manager records an item-level error and the task can still report as completed, so the report is the only honest answer to "did everything arrive".

Permissions need a decision rather than a default. Shared drive permissions come across when you map each Google group to a Microsoft 365 group with the same membership in the identity map, which means the groups have to exist in Microsoft 365 first. File-level permissions are off by default. External sharing links are not recreated, so anyone outside the company who had a link will need a new one. Only the latest version of each file is migrated by default, and delta runs pick up what changed after the first pass.

What we do with that: scan, read the report, fix the long paths and the ownership gaps, then run for real. The scan costs a day and it is the cheapest day in the project.

The things you rebuild by hand

Every migration on this route leaves the same short list, and it is better written down in week one than discovered on cutover weekend.

Groups. There is no vendor tool for Google Groups. A plain mailing list becomes a distribution group, created and populated in bulk. A collaborative inbox with years of stored conversations is a different question: a shared mailbox handles the future, and the archive needs its own decision.
Delegation. Microsoft turned calendar permission and delegate migration off in June 2024, so calendar sharing is a rebuild. Mailbox delegates can still be moved with cmdlets, and only the delegations the person actually accepted in Google, which is a good reason to confirm who delegates to whom before the run rather than after.
Rooms and resources. Room calendars and their bookings are recreated in Exchange Online. Ask for the next month of bookings as a list before the old system goes quiet.
Labels, filters and signatures. Filters arrive switched off, categories do not map to labels neatly, and signatures are per-client settings that nobody migrates for you.

Authentication and the MX hour

The MX change is the last step, not the first. Until the final batch is verified, the routing subdomains carry mail in both directions and the main domain still points where it always did. When the MX moves, authentication has to move with it, in the same change window.

SPF needs the Microsoft include, DKIM is enabled in the Microsoft security portal and published as two CNAME records, and the DMARC record at _dmarc stays where it is but needs rechecking, because the sender that has to align with it is now Exchange Online. Retire the Google DKIM key only after the last mailbox has moved, not before, or you will break signatures for the people still on the old system.

; SPF once Exchange Online is the sender
example.com.   3600   IN   TXT   "v=spf1 include:spf.protection.outlook.com -all"

If you keep third-party senders, an invoicing system, a CRM, a marketing platform, each one needs its own include or its own authenticated subdomain, and the record still has to stay inside the SPF lookup budget. Our Microsoft 365 SPF, DKIM and DMARC setup guide has that part in order. Check the domain the day the MX changes rather than waiting for a customer to tell you that your invoices land in spam.

One more reason to treat this hour carefully: a message that fails authentication after a migration does not look like a migration problem to the people receiving it. It looks like you.

How Guanacos Tech helps

We run this route end to end for small and mid-sized teams: the user and licence mapping, the routing subdomains, the mail batches, the Drive scan and the file runs, the group and delegation rebuild, and the authentication change on cutover day. In English and Spanish, across North America and Latin America, with Google-certified engineers who have worked both platforms since 2018. The scope of the route is on the Google Workspace to Microsoft 365 migration page, and the wider service, including file and tenant moves, is on the email and data migration page. A 30-minute call is enough to turn this checklist into dates for your own company and to name the items somebody on your side will have to rebuild.

Google Workspace to Microsoft 365: the migration checklist, in the order that keeps mail flowing