Moving From Google Workspace to Microsoft 365

A Google Workspace to Microsoft 365 migration is the process of moving an organisation’s mail, calendars, contacts and files out of Google’s tenancy into a Microsoft 365 tenant, then repointing the domain’s mail flow and identity to Microsoft. Microsoft supplies free first-party tooling that handles the bulk of the copying. The difficulty is not the copying. It is the handful of things Google does that Microsoft has no equivalent for, and the two weeks afterwards when users discover them one at a time.

This post is about mechanics only. If you are still deciding, read which platform suits your business first and come back.

Microsoft’s own tools do most of the copying, and they are free

There are two separate tools and they do not talk to each other.

Mail, calendars, contacts, mail rules and tasks move with the automated batch migration tool in the Exchange admin center. Per Microsoft Learn, it “can transfer your organization’s mail, rules, calendars, and contacts from Google Workspace to Microsoft 365”, and Microsoft recommends the automated method because it completes several of the required Google admin console steps for you.

Files move with Migration Manager, reached from the Microsoft 365 admin center under Setup, then Migration and imports. Microsoft’s own FAQ is blunt about the alternatives: “Currently, Migration Manager is the tool to use for migrating Google content.” For tenants with fewer than 300 licences at the time the project is created, Microsoft enables a cut-down version called Migration Manager Lite, which skips the scan, destination-mapping and identity-mapping steps. On anything beyond a handful of users, that is the wrong tool. You want the scan report and you definitely want identity mapping.

Third-party migration tools still have a place, mostly for tenant-to-tenant work, Google Sites, or when you need reporting Microsoft does not produce. For a standard 10 to 200 seat move, the native tooling is adequate.

What migrates cleanly

• Mail content and folder structure, including Gmail labels rendered as Exchange folders.
• Calendar events on users’ primary calendars.
• Contacts, up to three email addresses per contact.
• Mailbox delegates, Send As, and mail rules.
• Google Tasks, if you pass -MigrateTasks when you create the batch. Task lists become task folders. Note that incremental sync is not supported for tasks that have already migrated.
• Rooms and resources, if you enable the Admin SDK API and add the resource calendar read-only scope to domain-wide delegation. Google resources map to Exchange resource mailboxes and Google buildings map to distribution groups.
• Drive files and folders, including version history, and shared drive permissions if you map identities properly first.
• Google Docs, Sheets and Slides, converted on the way through.

What does not migrate, and what users will complain about

This is the section to read to your leadership team before you commit to a date.

Gmail labels are not folders. Google’s own help documentation states plainly that “labels are different from folders” and that you can apply several labels to one email. Exchange has folders, and a message sits in exactly one. Anything labelled three ways has to become three copies or one copy in one folder. Neither answer is what the user had. Microsoft’s guidance is to use the -ExcludeFolder parameter when starting batches from Exchange Online PowerShell to strip out labels that apply to large numbers of messages, which reduces both duplication and mailbox size. Decide this per label, with the business, before you migrate. Do not discover it afterwards.

Google Docs stop being Google Docs. During migration the Google Export API converts .gdoc to .docx, .gsheet to .xlsx and .gslide to .pptx. The originals in Drive are untouched. What does not survive the conversion is everything that was never a document feature to begin with: suggestion mode history, Apps Script attached to a Sheet, IMPORTRANGE and other cross-document live links, and add-ons. Any spreadsheet that is really a small application needs to be rebuilt, not migrated. Find those first. There are always two or three and they are always load-bearing.

Shared calendars and calendar delegation. Microsoft’s documentation is explicit that shared calendars and event colours are not migrated, and that room bookings are not migrated. More significantly, as of June 2024 the option to migrate permissions and delegates for calendars is turned off worldwide. Mailbox permissions and delegates still migrate. Calendar permissions do not. Every executive assistant who manages a principal’s diary will need that relationship rebuilt by hand on day one.

Vacation and auto-reply settings are not migrated. Trivial until you cut over the week someone is on leave.

Google Sites and Google Maps cannot be exported, so Migration Manager does not move them. Google Drawings come across as PNG files. Google Forms migrate, but only if you designate a Forms destination on the task. Shortcut files are skipped entirely.

Orphaned files. Microsoft does not scan unorganised or orphaned files in Google, so they are neither migrated nor reported. If a departed employee’s content ended up unparented, it does not appear in any report. It just is not there afterwards.

External sharing links break. Migration Manager does not recreate external sharing links and does not share content with external collaborators, deliberately. If your clients or suppliers have bookmarked a Google Drive link, every one of those links dies at cutover and has to be reissued from SharePoint.

Google Groups do two jobs at once. In most Workspace tenancies a group is simultaneously a mailing list, a Drive permission holder, and sometimes a calendar. Microsoft splits those across distribution lists, Microsoft 365 groups, security groups and shared mailboxes. Before you migrate files, work out for each group which job it is really doing, then recreate the file-permission side as a Microsoft 365 group with matching membership and map it in Migration Manager’s identity mapping. Microsoft’s FAQ makes this a prerequisite for shared drive permissions to land correctly, not an optimisation.

Anything authenticated with Google SSO. This is the one that catches people. Where Google Workspace is acting as the SAML or OIDC identity provider for third-party SaaS, or staff have been signing in to a tool with “Sign in with Google”, that trust relationship does not migrate. Each application has to be reconfigured against Microsoft Entra ID, which means touching each vendor, and some of them will want a plan upgrade to support SAML. Separately, check API controls and domain-wide delegation in the Google admin console for service accounts that read Workspace data on behalf of users. Those integrations are invisible to end users right up to the moment they stop working. Inventory both lists before you set a date.

Identity and domain handling decides your sequencing

Microsoft 365 identity runs on Microsoft Entra ID, Microsoft’s cloud-based identity and access management service. Your users need to exist there before anything can be delivered to them.

The mail migration requires a specific and slightly counter-intuitive DNS arrangement. Microsoft’s prerequisites call for two routing subdomains: one added in Google Workspace pointing at Microsoft 365 (for example o365.yourdomain.com.au), and one added in Microsoft 365 pointing back at Google (for example gsuite.yourdomain.com.au). Both must verify and go Active. Microsoft warns that using the built-in tenantname.onmicrosoft.com domain for routing instead of a subdomain of your primary domain “occasionally causes issues that Microsoft is not able to assist with”.

Every user is provisioned in Microsoft 365 as a mail user first, with an ExternalEmailAddress pointing at their Google routing address, before being converted to a mailbox by the migration itself. Get the primary addresses matching across both platforms. Where they do not match, the user needs a proxy address at the primary domain.

Microsoft also recommends disabling messaging records management and archive policies during the migration, because retention and archiving actions during a copy make messages look missing during verification when nothing has actually been lost.

Two cutover approaches, and the one most businesses should pick

Staged coexistence. The dual-subdomain routing above exists so mail keeps flowing to both platforms while batches run. You migrate in groups, the MX record moves once, and the remaining Google users receive their mail via forwarding until their batch completes. This is the approach the Microsoft tooling is built around and it is the right default for anything above about 20 users. The trade-off is a period of split-brain where free/busy lookups across the boundary do not work properly and internal replies occasionally take an odd path.

Single cutover. Everything migrates over a weekend, MX moves once, Google goes read-only Monday morning. Cleaner conceptually, and fine for small tenancies with modest mailboxes. The risk is entirely on throughput: contact and calendar throughput is capped by your Google tenant’s service account quota, and individual messages are limited by default to 35 MB (configurable up to 150 MB). If a large mailbox does not finish, you have no fallback because the MX has already moved.

Pick coexistence unless the tenancy is genuinely small. The extra fortnight of dual routing costs less than a failed weekend.

Realistic sequencing

1. Audit and inventory. Super admins, third-party OAuth grants, domain-wide delegation, SSO applications, forwarding rules, shared drives with no manager, Google Groups and what each one actually does. We cover this in detail in audit the Google tenancy before you touch anything.
2. Take an independent backup of the Google data before you change anything. Migration tools copy rather than move, but a rollback point that does not depend on either vendor is cheap insurance. See a proper backup of the Google data.
3. Build the Microsoft 365 tenant. Licensing, Entra ID, groups, SharePoint site structure, security baseline.
4. Provision mail users and verify both routing subdomains.
5. Migrate rooms and resources first. Microsoft recommends starting resource onboarding before regular mailbox onboarding and finishing it after all mailboxes are done.
6. Run a pilot batch. Include at least one executive assistant, one heavy label user and one person with a spreadsheet that does something clever.
7. Scan Drive, map identities, pre-create the Microsoft 365 groups that will hold shared drive permissions.
8. Migrate files ahead of mail. File migration is slower and tolerates delta syncs. Mail cutover is the hard deadline.
9. Move mail in batches, then move MX.
10. Delta sync files, rebuild calendar permissions, reissue external links, repoint SSO applications.
11. Leave Google Workspace running, read-only, for at least one billing cycle. Do not cancel the subscription on cutover day.

For the Microsoft-side build, our general Microsoft 365 migration guide covers the tenant configuration that applies regardless of where you came from.

The parts that always cause grief

Delta syncs punish tidiness. Migration Manager treats a renamed file or folder as a brand new object, so reorganising Drive between passes duplicates everything below the renamed folder. Freeze the source structure for the duration.

Data volume never matches the admin console. Google only started counting the size of its own proprietary file types on 2 May 2022, so anything created or modified before that date returns a scanned size of one byte. Your scan report will understate the job.

Path length and file names bite late. Destination URLs over 400 characters fail, drives with a forward slash in the name are unsupported, and duplicate file names in the same folder get renamed with (1), (2) suffixes.

And the cultural one, which no tool solves: Google’s sharing model is permissive by default and SharePoint’s is not. Users who were used to sending a link to anyone will find themselves blocked, and will describe this as the migration breaking things. Decide your external sharing policy before cutover, communicate it as a deliberate change, and staff the help desk properly for the first fortnight.

If you are keeping some Google services rather than leaving entirely, running both platforms side by side is a supportable position, but it needs to be a decision rather than a leftover.

Worth saying plainly, because this post points one direction: we are a Microsoft partner, and we also administer Google Workspace tenancies as daily work. We do not treat a move to Microsoft 365 as automatically correct, and a fair share of the businesses that ask us about this migration are better off staying where they are. If yours is one of them we will tell you, which is the only reason the rest of this advice is worth reading.

Book a scoping session before you commit to a cutover date. We will run the inventory, produce the list of things that will not migrate, and give you a sequenced plan you can put in front of your board. Call 1300 028 324 or get in touch at https://techassist.au/contact/.