Migrate between Google Workspace and Microsoft 365 (2026 cross-platform guide)
Mergers, acquisitions, changing internal standards — cross-platform migrations between Google Workspace and Microsoft 365 (in both directions) are more common than you might think. This guide details the tools, limits and realistic timeline for migrating without data loss.
Table of contents
Why migrate between the two platforms?
Cross-platform migrations happen more often than you might think. Based on our experience at AfricWebHosting, approximately 5 to 10% of our clients switch ecosystems within the first 2 years. Here are the typical cases:
- Merger or acquisition: Company A (on Google) is acquired by Company B (on Microsoft, or vice versa). The group decides to unify on a single platform. This is the most common case and often the most urgent.
- Change of internal standard: a startup on Google Workspace reaches 30–50 employees and its finance/legal team requires Word, advanced Excel, Outlook and Conditional Access. Strategic decision to switch to M365.
- Client pressure: an agency whose clients all share documents via SharePoint/Teams is constantly converting from Google Docs. The opportunity cost eventually justifies the migration.
- Cost reduction: rarer, but some SMBs move from M365 Premium (€22/user/month) to Google Workspace Standard (€14.90/user/month) during a budget restructuring.
Whatever the direction (Google → Microsoft or Microsoft → Google), the logic is the same: migrate emails, calendars, contacts, files and admin configurations — in that order of priority.
This guide covers both directions. The tools and complexity differ slightly depending on the direction.
Prerequisites for a cross-platform migration
Before starting, gather these elements — without them the migration will be chaotic:
- Admin access on both source AND target: you need a Super Admin account on the source tenant (Google or Microsoft) AND a Global Admin account on the destination tenant. Without this, migration tools cannot authenticate.
- Account mapping: one Google user = one Microsoft 365 user. Prepare a CSV table with three columns:
source_email,target_email,display_name. If addresses change during migration (merger with domain change), document it explicitly. Incorrect mapping = emails delivered to the wrong mailbox. - Shared resources inventory:
- Google → M365: list all Shared Drives, Google groups, resource calendars (meeting rooms), service accounts.
- M365 → Google: list all SharePoint libraries, Microsoft 365 groups, Exchange resource calendars, shared mailboxes.
- Data size: measure the total size of each mailbox (emails + Drive/OneDrive) before starting. Google Workspace Admin Console → Reports → User usage gives the size per user. M365 Admin Center → Active users → Export gives the same information. Migration tools sometimes limit throughput — knowing the volumes allows planning the timing.
- Rollback plan: keep the old tenant active in read-only mode for 30 days after migration. Do not close source licences immediately — you may need to recover a forgotten email or file.
Migrating emails, calendars and contacts
This is the most critical part — and the most tooled.
Direction: Google Workspace → Microsoft 365
Use Microsoft Migration Manager (built into the M365 Admin Center, Setup → Migration section). It natively supports Gmail → Exchange Online migration via IMAP and via the Google Workspace API. The Google API method is recommended — it is faster and better preserves folder structure. Steps:
- In Migration Manager, create a "Google Workspace" project.
- Connect your Google Super Admin account (OAuth).
- Upload your mapping CSV.
- Launch pre-scan to estimate volumes.
- Launch the initial migration (J-3 to J-5 before cutover for large volumes).
- On cutover day, run the delta pass (last 24h emails), then switch MX records.
Known limits: ~30 GB/mailbox per run (multiple runs possible), Gmail labels become Exchange folders (not always cleanly), HTML signatures may be lost or poorly formatted. Emails older than 2010 may have encoding issues.
Direction: Microsoft 365 → Google Workspace
Use the Google Workspace Migration Tool for Microsoft Exchange (GWMME), downloadable from the Google Workspace Admin Console. It connects to Exchange Online via EWS (Exchange Web Services). Steps similar to the above but from the Google console. Limits: same ~30 GB/mailbox per run ceiling, some complex recurring Exchange meetings may be imperfectly transcribed in Google Calendar.
Contacts: export as vCard (.vcf) or CSV from the source tenant, import into the target tenant. Simple but manual.
Calendars: complex recurring events (weekly meetings with exceptions) do not always migrate perfectly. Plan a manual check on the 5 most active calendars after migration.
Migrating files: Drive ↔ OneDrive / SharePoint
File migration is often longer than email migration — and errors are less visible (a misplaced file can go unnoticed for weeks).
Google Drive → OneDrive / SharePoint
Microsoft offers Mover.io (integrated into Migration Manager) which natively supports Google Drive → OneDrive and Google Shared Drives → SharePoint migration. This is the recommended tool:
- Connect both tenants (OAuth).
- Map users (same CSV as for emails).
- For Shared Drives, map to destination SharePoint libraries.
- Launch the migration. Mover.io generates a migration report with succeeded/failed files.
Estimated throughput: plan 1–2 days per 100 GB per user, depending on connection speed and number of small files (millions of files < 1 MB are slower to migrate than a few large files).
OneDrive / SharePoint → Google Drive
Less natively tooled. Options:
- Mover.io also supports the M365 → Google Drive direction (via SharePoint/OneDrive connector).
- MultCloud (third-party tool, freemium): connects both clouds and transfers in the background. Simple for small volumes (< 50 GB).
- PowerShell script + rclone: for large migrations (500 GB+), rclone with OneDrive and Google Drive connectors is reliable and free. Requires a technician able to write and monitor scripts.
Key points:
- Fine-grained permissions (sharing with external users) do not migrate — they must be recreated manually in the target tenant.
- Native Google Docs/Sheets/Slides files (.gdoc format) are converted to .docx/.xlsx/.pptx when migrating to M365. Layout may differ slightly. Check the 20 most important files after migration.
- Word/Excel/PowerPoint files migrate from M365 to Google Drive without conversion and open in Google with the Office compatibility extension.
What does not migrate: the honest list
Here is what you lose in a cross-platform migration — without exception in our field experience:
| Item | Google → M365 | M365 → Google |
|---|---|---|
| Teams / Google Chat message history | Lost (not migratable) | Lost (not migratable) |
| Meeting recordings | Migrate as video files | Migrate as video files |
| Connected third-party apps (Zapier, Slack, etc.) | Must be manually reconfigured | Must be manually reconfigured |
| Google Forms | Export PDF, recreate in M365 Forms | N/A |
| Microsoft Forms | N/A | Export responses CSV, recreate in Google Forms |
| Zapier workflows on G/M accounts | Reconfigure with new accounts | Same |
| HTML email signatures | Often lost or malformed | Same |
| Email filter rules | Not migrated, must be recreated | Not migrated, must be recreated |
| Google Sites / SharePoint Intranet | Must be rebuilt | Must be rebuilt |
| Excel VBA macros | Work in M365 (native) | Not supported in Google Sheets |
The most impactful items for most SMBs are: loss of chat history (Teams ↔ Chat), the need to reconfigure third-party apps, and recreating email signatures. Inform your team before migration — transparent communication reduces post-migration support tickets by 50%.
Realistic timeline and our AfricWebHosting offer
Here is the schedule we follow for a cross-platform migration of 10 users (email + Drive/OneDrive data):
| Phase | Duration | Actions |
|---|---|---|
| Preparation | 5 business days | Inventory, mapping CSV, target tenant creation, test DNS config, third-party app audit |
| Pre-migration | J-3 to J-1 | Initial email migration (90% of data), background file migration, tests on pilot accounts |
| Cutover | 2–4 hours | Email delta pass, MX switch, SPF/DKIM/DMARC config, delivery test, team notification |
| Post-migration | 5 business days | User support, signature recreation, third-party app reconnection, critical file verification |
Total for 10 users: approximately 1 week of preparation + 2 days of cutover + 1 week of post-migration.
For 50 users, double the preparation phase and add 1 cutover day.
For 100+ users, plan 3–4 weeks of preparation and a multi-wave cutover (by department).
Our AfricWebHosting cross-platform offering
We offer turnkey cross-platform migration packages:
- Starter (up to 10 users): €590 excl. VAT — includes preparation, email + file migration, cutover, post-migration (5 days of support)
- Standard (11 to 50 users): €990 excl. VAT — same + team training (2h video call) + migration report
- Enterprise (51 users and above): on request — phased migration, HR coordination, 30-day priority support
These packages do not include the cost of destination licences (Microsoft 365 or Google Workspace). Contact us for a personalised quote — we respond within 24 business hours.
If you are preparing your migration, also read our related guides: Migrate to Microsoft 365 from IONOS/OVH/Gandi and Microsoft 365 vs Google Workspace: how to choose?