Migrating from Google Workspace to Microsoft 365
A practical migration playbook for moving from Google Workspace to Microsoft 365 — workloads, tools, and pitfalls.
Moving from Google Workspace to Microsoft 365 isn't a like-for-like swap — the products solve similar problems with different shapes. Done well, it's straightforward; done badly, it's a six-month tax on the IT team.
What needs to migrate
A typical scope:
- Identities — Google users → Entra ID accounts.
- Email — Gmail mailboxes → Exchange Online.
- Calendars — Google Calendar → Exchange Online calendars.
- Contacts — Google Contacts → Outlook contacts.
- Files — Google Drive (personal) → OneDrive; Shared Drives → SharePoint.
- Documents — Google Docs/Sheets/Slides → Word/Excel/PowerPoint (conversion happens automatically; formatting often needs touch-up).
- Sites — Google Sites → SharePoint communication / team sites.
- Groups — Google Groups → Microsoft 365 Groups or distribution lists.
- Chat — Google Chat history → typically not migrated (too different).
- Meet recordings → OneDrive / SharePoint.
- Forms → Microsoft Forms.
- Email domain cutover — the big day.
Migration tools
Microsoft ships first-party tools that cover the bulk of the scope:
- Exchange admin center → Migration for Gmail (IMAP-based migration with OAuth).
- Microsoft 365 Migration Manager for files, with cloud-to-cloud Google Drive support.
- Migration Manager also handles SharePoint sites from Google Sites in limited cases.
Third-party tools cover gaps and add concurrency:
- Quest On Demand, BitTitan MigrationWiz, CodeTwo, AvePoint Fly all support full Google → Microsoft migrations.
- For mid-to-large estates, a third-party tool plus a partner is the typical approach.
A realistic playbook
A migration of a couple hundred users typically runs:
Phase 1 — Plan (2–4 weeks)
- Inventory Google estate — users, files, sites, groups, custom apps.
- Decide on identity strategy — fresh Entra ID accounts, or sync existing AD.
- Decide on co-existence period — usually 1–4 weeks where both systems run in parallel.
- Set up Microsoft 365 tenant, domain, basic baseline.
Phase 2 — Prepare (1–2 weeks)
- Provision Entra ID users.
- Buy and assign Microsoft 365 licences.
- Configure DNS for co-existence (split routing so mail still flows to Gmail until cutover).
- Pilot migration with 5–10 users; iterate on issues.
Phase 3 — Migrate (2–8 weeks depending on size)
- Migrate user data in waves — typically by department or geography.
- Provide users with Outlook, Teams, OneDrive training during their wave.
- Run a secondary sync before final cutover to catch new content.
Phase 4 — Cutover (1 day)
- Update DNS MX records to point to Exchange Online.
- Run a final delta migration.
- Disable Google email forwarding.
- Validate mail flow.
Phase 5 — Stabilise (2–4 weeks)
- Help-desk surge for adoption questions.
- Track migration completeness via reports.
- Hold Google Workspace open in read-only for 30 days for missed content.
Common pitfalls
- Shared drives with complex permissions translate roughly into SharePoint. Plan permissions before migration, not after.
- Google Docs formatting doesn't survive conversion intact — heavy users feel this.
- Google-specific integrations (Apps Script, native Google add-ons) don't have direct Microsoft equivalents.
- Calendar invite cutover — meetings scheduled before cutover need handling so they don't lose responses.
- User training is usually the biggest underestimate. Plan for it.
Why people migrate
The usual drivers:
- Security and compliance consolidation (Defender, Purview, Conditional Access).
- Identity and device management unification with Windows estate.
- Existing Microsoft enterprise relationship — EA, Azure, Dynamics.
- Specific app needs that Microsoft does better (Excel, deeper Office desktop tools).
When the move makes sense for those reasons, the migration mechanics are well-trodden — it's a project, not an experiment.