We migrated 150+ users from Google Workspace to Microsoft 365. Here is what the documentation does not prepare you for.
If you search for how to migrate from Google Workspace to Microsoft 365, you will find good official documentation. The migration tools exist. The process for moving mailboxes, calendars and contacts is well-understood. The Drive to OneDrive migration tooling works.
The documentation covers the technical mechanics. It does not cover what actually makes these migrations difficult.
The technical migration takes days. The workflow migration takes months.
Google Workspace and Microsoft 365 are not functionally equivalent. They have different capabilities, different mental models and different integration points. Users who have spent years in Google Docs have built habits around features that don't have direct Microsoft equivalents - real-time collaborative editing in Google Sheets works differently from Excel for the Web, Google Forms doesn't map cleanly to Microsoft Forms and the interaction model of Google Chat is different from Teams.
The mistake is treating the migration as a data move. It's actually a productivity platform change that happens to involve moving data. Users need training not just on "where did my files go" but on "how do I do my actual work now".
Organisations that do this well front-load training and change management. Organisations that do it poorly complete the technical migration and then spend months fielding support requests from users who can't find their documents or don't know how to use Teams effectively.
If the organisation uses Slack alongside Google Workspace - which is common - the Slack to Teams migration is a parallel workstream that deserves its own timeline and resources.
Slack channel history doesn't import cleanly into Teams. The tools that exist for this migration produce varying results depending on Slack plan tier and message types. Integrations that Slack was handling - connecting to internal tools, running bots, workflow automations - need to be recreated in Teams or replaced.
Treating the Slack migration as a side task that can happen in parallel with the Google Workspace migration is a predictable way to end up with an incomplete Teams deployment and a user base that still defaults to Slack because the Teams alternative wasn't ready when they needed it.
Google Drive's sharing model is powerful and informal. Users share files with specific people, share with "anyone with the link" and create cross-departmental spreadsheets that have been shared ten different ways over three years.
OneDrive for Business has a more structured permissions model. The migration tooling moves files, but the permission mapping isn't always clean - especially for files with many collaborators or complex inheritance chains.
Before the technical migration, audit the permission state of Drive. This usually reveals sharing practices that IT didn't know were happening. External shares to personal Gmail accounts or contractors need decisions: migrate them, block them or handle them case by case. Making these decisions mid-migration slows everything down.
When users have had Google accounts for years, they've signed up for dozens of third-party services with their work Google credentials. These aren't visible to IT. After the Google Workspace tenant is deprovisioned, some of those services will lose authentication and the user won't be able to recover access without the original Google account.
Communicate this explicitly before migration. Give users time to update their third-party account recovery details. The services that get caught in this way are usually not work-critical, but the user experience of losing access to a service because of an IT migration they didn't fully understand creates distrust that lingers.
At 150 users, you can still do white-glove migration support - a helpdesk resource dedicated to migration questions, brief walk-through sessions for departments and a rapid response loop for the first week after cutover.
This doesn't scale to 5,000 users. At larger scale, the investment in self-service documentation, training materials and a migration FAQ that answers the questions users actually have becomes the difference between a successful migration and a prolonged disruption.
The organisations that handle large-scale migrations well treat documentation as a product. They test it with real users before cutover and iterate based on what questions still come in. It's the same discipline as building user-facing software - the quality of the documentation is a feature.
The migrations we've seen succeed consistently had one thing in common: a designated user advocate inside the organisation who wasn't the IT team. Someone whose job, for the duration of the migration, was to represent the user experience rather than the technical completion criteria.
Technical migration success is binary - either the data moved or it didn't. User adoption success is a gradient and it decays if it isn't actively managed. The organisations that treat migration as done when the technical work is complete typically see productivity dips that persist for months. The ones that treat day one of the new platform as the beginning of the work rather than the end get back to baseline faster.