Every G Suite to Office 365 migration starts the same way: an executive decision made for licensing, compliance, or merger reasons, followed by an IT team discovering that "move the email" is maybe 40 percent of the project. The Gmail data itself moves well. What does not move — or moves with an asterisk — is the connective tissue: labels, Drive sharing semantics, Google Docs formats, Sites, Forms, and a workforce whose muscle memory is entirely Google-shaped.
We are mid-flight on exactly this engagement right now: a professional-services firm, a couple of thousand seats, Google-native since 2011, acquired by a Microsoft-shop parent that wants one tenant and one compliance boundary. We have run this movie before with smaller casts, and the plot is consistent enough that we can tell you in advance where the fidelity gaps are and which ones users will actually notice.
This post is the honest inventory: what migrates cleanly, what migrates with transformation, what does not migrate at all, and how to run coexistence so the long tail does not hurt.
Mail: high fidelity, with a label-shaped asterisk
Gmail to Exchange Online is the mature part of this market. We use BitTitan MigrationWiz for these projects — it talks to Google's APIs rather than scraping IMAP, which matters for throughput and for calendar fidelity. Message bodies, attachments, and dates arrive intact. The asterisk is labels.
Gmail does not have folders; it has labels, and a message can carry five of them. Exchange has folders, and a message lives in exactly one. The migration tool has to make a choice, and the standard choice is label-to-folder mapping with the message copied into each corresponding folder. A heavily labeled mailbox can grow 20–30 percent in the process, and users open Outlook to find what looks like duplicated mail. It is not corruption; it is a data-model impedance mismatch. Put it in the communications, with a screenshot, before cutover — the difference between "known behavior" and "migration bug" is whether you told people first.
Two more mail-side notes from the field. First, Gmail's "All Mail" is an archive view, not a folder; decide explicitly whether you migrate it (usually no — it duplicates everything). Second, watch API quotas: Google throttles per-user and per-project, so your throughput planning is about concurrency across many mailboxes, not speed within one. We schedule large batches across nights and plan on realistic per-mailbox rates rather than the lab numbers.
Calendar and contacts: better than you fear, worse than perfect
Calendars migrate with owners, events, and most recurrence patterns intact. The failure modes are at the edges: exotic recurrence rules, events with dozens of guests where attendee status partially resets, and — the big one — resource calendars. Google resource calendars (rooms, projectors, the pool car) need to be rebuilt as Exchange room and equipment mailboxes, and existing bookings re-pointed. We inventory resources in week one and rebuild them in Exchange Online before user migration, so that migrated events referencing rooms have somewhere to land.
Delegation is the other quiet breakage. Google calendar sharing is granular and viral; users share calendars with each other constantly. None of that permission web migrates. We pull the sharing report, identify the heavy delegation clusters — executive assistants, dispatch teams — and rebuild those relationships manually in Exchange during their cutover week. It is an hour per cluster and it prevents the loudest tickets you will get.
Contacts move cleanly. Contact groups mostly do. Nobody has ever thanked us for the contacts migration, which is what success looks like.
Drive: a mapping exercise, not a copy job
Google Drive to OneDrive for Business and SharePoint Online is where the project earns its architecture. The mistake is treating it as a file copy. It is a re-homing of three different things Google blends together: personal files, shared-with-me relationships, and Team Drives.
Our mapping rule set, which has survived several engagements:
- My Drive maps to the user's OneDrive. Straightforward.
- Team Drives map to SharePoint document libraries, one site per Team Drive or per department, depending on how disciplined the Team Drive sprawl is. Usually it is not disciplined; budget a rationalization pass.
- Shared-with-me does not migrate, because it is not data — it is a view of other people's data. When the owner's file moves, the old sharing link dies. This is the single largest source of post-migration tickets, and no tool fixes it. Communications and a "how to re-share in OneDrive" one-pager fix it.
Then there is format conversion. Native Google Docs, Sheets, and Slides files are not files in the ordinary sense; they are pointers to cloud objects. Migration tooling exports them to Office formats — Docs to .docx, Sheets to .xlsx, Slides to .pptx. Fidelity is good for documents, decent for slides, and genuinely risky for complex Sheets: formulas that exist only in Google (QUERY, IMPORTRANGE, ARRAYFORMULA semantics) break on conversion. We inventory Sheets above a complexity threshold and hand the top offenders to their owners for manual rebuild in Excel. On the current engagement that list was about 150 files out of 400,000 — small in count, but they were payroll trackers and project dashboards, exactly the files that cannot silently break.
The things that do not move at all
Say these out loud in the steering committee early, because each one is somebody's favorite tool:
- Google Sites has no migration path. Inventory them, then triage: rebuild the living ones in SharePoint, screenshot-and-archive the dead ones. Of 90 Sites at our current client, 11 were worth rebuilding.
- Google Forms likewise — rebuild in Microsoft Forms, re-link the response Sheets to Excel.
- Hangouts / Chat history does not migrate. Teams starts fresh. Announce the retention implications to legal before, not after.
- Google Groups used as distribution lists rebuild as Exchange distribution groups or Office 365 Groups; Groups used as forums have no clean equivalent — most retire.
- App Scripts and Drive-integrated third-party apps — inventory the OAuth grants; every one is either a workflow to rebuild in Flow/SharePoint or a vendor conversation.
None of these are project-killers. All of them are schedule-killers if discovered in the cutover month.
Coexistence: dual delivery, one direction, short duration
For a 2,000-seat estate we do not attempt cutover in a weekend, which means mail coexistence. The pattern that works: MX stays pointed at Google, Gmail dual-delivers or forwards migrated users to Office 365, and free/busy across the boundary is accepted as imperfect for the duration. Calendar coexistence between Google and Exchange is technically possible with connectors and practically disappointing; we compress the migration calendar instead of engineering around it. Six weeks of wave migrations beats six months of "why can't I see her availability" tickets.
Directory-wise, this client had no on-prem AD tie to Google — Google was the directory. We stood up Azure AD as the target identity platform, provisioned from the HR feed, and treated the Google directory as read-only reference. If you do have AD with GCDS syncing to Google, the sequencing is friendlier: Azure AD Connect alongside, migrate, then retire GCDS.
Change management is half the budget, and that's correct
Here is the uncomfortable part. A Google-native workforce does not experience this as an upgrade. Gmail's search is genuinely excellent; conversation view works differently in Outlook; real-time co-editing exists in Office Online but people have to be shown; and "just share the doc" habits produce a week of broken-link frustration. The technical migration can be flawless and the project can still be judged a failure in the hallway.
What has worked for us: floor-walkers during each cutover wave, a one-page "Google to Microsoft translation card" (Drive is OneDrive, Team Drive is SharePoint, Hangouts is Teams, Sheets is Excel), and — most effective — migrating the executive team in the second wave, not the last one. When leadership lives the change early, the tone of every subsequent complaint conversation is different. We also keep Google running read-only for 60 days post-cutover as a safety net; almost nobody uses it after week two, but its existence lowers the temperature of the entire project.
Budget-wise, on these engagements roughly half the professional-services spend goes to migration engineering and half to training, comms, and floor support. Clients who cut the second half spend it anyway, later, as help desk overtime.
If you're facing this
We have moved organizations off Lotus Notes, off Exchange 2003, and off G Suite, and the G Suite moves are the ones where user experience planning decides the outcome. If a G Suite to Office 365 migration is on your 2019 roadmap — merger-driven or otherwise — get in touch and we will walk you through the fidelity inventory against your actual estate before you commit to a timeline.