Why migrations go wrong

Google Workspace to Microsoft 365 is one of the most common migration paths across the region. It's also one of the most underestimated. Organisations regularly go in expecting a straightforward data transfer and discover mid-project that permissions don't translate, integrations break, and users can't find their files.

The technical data transfer is solvable. The bigger risks are in planning — specifically, what you audit before you start.

⚠️
Microsoft's own documentation notes that its native migration tool is unaware of archival and records management (MRM) policies. Messages moved or deleted by those policies appear as "missing" during migration — which looks like data loss, but isn't. Disabling MRM policies before migration begins is a prerequisite most teams miss.

What migrates — and how cleanly

The table below summarises the main data types and their migration fidelity, based on Microsoft's official documentation and guidance from BitTitan MigrationWiz, AvePoint Fly, and ShareGate.

Data Type Google Source M365 Destination Status
Email Gmail Exchange Online / Outlook Migrates cleanly
Calendar Google Calendar Outlook Calendar Partial — event colours lost
Contacts Google Contacts Outlook Contacts Max 3 addresses per contact
Personal Drive files Google Drive OneDrive for Business Migrates cleanly
Shared Drives Google Shared Drives SharePoint / Teams Needs pre-migration mapping
Google Docs / Sheets / Slides Google formats .docx / .xlsx / .pptx Converted — formatting risk
Gmail labels Gmail labels Outlook folders / categories Converted to folders
Inbox rules Gmail filters Outlook rules Migrated but disabled by default
Custom Gmail tags Gmail — Not migrated
Google Sites Google Sites SharePoint sites Embedded content lost
Google Forms Google Forms Microsoft Forms Now supported (Migration Manager)
Google Apps Script Custom automations — Not migrated — rebuild required
Google Chat history Google Chat Microsoft Teams Not migrated
External sharing links Drive sharing links — Broken post-migration
Google Maps in Drive Google Maps — Not exportable by Google
Vault retained data Google Vault Microsoft Purview Requires Vault licence + planning

The five risks teams consistently underestimate

1. Shared Drive permission complexity

Google Shared Drives don't map 1:1 to SharePoint. The permission model is fundamentally different — Google handles nested permissions elegantly at folder level, while SharePoint requires manual reconfiguration. Before any Shared Drive migration begins, a matching Microsoft 365 group must be created in the destination tenant with identical memberships, and identities mapped in Migration Manager. Teams commonly discover this only when hundreds of folders are missing their access controls post-cutover.

2. Third-party app integrations and SSO

Every SaaS application that authenticates via Google Cloud Identity needs to be individually reconfigured to use Microsoft Entra ID. This includes tools like Salesforce, Slack, Zoom, HubSpot, Atlassian, and any platform with Google SSO enabled. For organisations with more than 20 SSO-integrated apps, Microsoft and migration practitioners recommend a phased cutover over 2–4 weeks rather than a single switchover.

ℹ️
Google Apps Script — custom automations your team may have built inside Docs, Sheets, or Calendar — has no equivalent in Microsoft 365. These must be identified, scoped, and rebuilt in Power Automate or other M365 tools before cutover. Missing them during the audit phase is a common source of post-migration disruption.

3. Data volume and Google throttling

Google throttles data exports to approximately 2.5GB per user per day via its APIs. For an organisation with 100 users averaging 10GB each, that translates to a minimum 40-day migration window using free tools. Third-party tools use techniques like bulk API calls and Azure BLOB staging to reduce throttling impact, but volume planning is essential regardless.

4. The document conversion trap

Google Docs, Sheets, and Slides are converted to Microsoft formats during migration. For simple documents this works well. For complex files — heavily formatted reports, Sheets with embedded scripts, Slides with video or advanced animations — conversion quality drops significantly. A post-migration QA pass on complex documents should be budgeted, particularly for finance, legal, and executive team content.

5. Change management and user adoption

Consistently cited by migration practitioners as the biggest single challenge — not the technical transfer. Users coming from Google have deep muscle memory: Gmail shortcuts, Drive search habits, Docs collaboration patterns. Moving to Outlook, OneDrive, and SharePoint is a genuine behaviour change, not just a tool swap. Migrations that budget for structured user training and a hypercare period in the first two weeks post-cutover have materially better outcomes.

🚨
Point of no return: DNS cutover — changing MX records to point to Microsoft 365 — cannot easily be undone. Verify all migration batches are in "Synced" status before taking this step. Once MX records switch, all new email routes to M365 regardless of whether user data has fully migrated.

Pre-migration checklist

  • Audit all SSO-connected third-party apps — build a reconfiguration plan for each before migration begins
  • Disable MRM and archival policies in Google Workspace before any mailbox migration starts
  • Identify all Google Apps Script automations — assess which need rebuilding in Power Automate
  • Map Shared Drive structures to SharePoint — recreate matching M365 groups before migration
  • Calculate total data volume per user — plan migration windows based on Google's ~2.5GB/user/day throttle
  • Inventory complex Google Docs/Sheets/Slides — flag for post-migration QA
  • Verify domain and email address alignment between Google Workspace and M365 accounts
  • Prepare user communications — notify teams ahead of migration, set expectations on access during transfer
  • Plan a hypercare period of at least two weeks post-cutover with dedicated IT support capacity
  • Export a Google Takeout backup as insurance before migration begins — full organisation exports can take up to 14 days

Choosing a migration tool

Microsoft's native Migration Manager (built into the M365 Admin Centre) handles email, calendar, contacts, Drive, and Shared Drives at no additional cost. It's a workable choice for straightforward migrations. For more complex environments — large data volumes, intricate Shared Drive structures, strict timelines — third-party tools offer meaningful advantages in throughput, permissions fidelity, and monitoring.

The tools most commonly used in the region include BitTitan MigrationWiz, AvePoint Fly, and ShareGate. Each handles the core workloads and offers pre-migration scanning to surface issues before data moves.

If you're planning a migration and want an independent assessment of your environment before committing to a tool or timeline, our technology advisory service covers migration planning as part of fractional CTO engagements across Singapore and Malaysia.

Sources