Why start with one page
In cutover week, nobody hands you an architecture diagram. You get a ticket that says "my email is gone", "my Drive link says access denied" or "Outlook shows last month's calendar". Most of these tickets come from how the move was built, not from a broken laptop. If you keep the whole move in your head as one page, you can place each ticket on that page within a minute, and that tells you whether you fix it or pass it to someone else.
This course is about the support side. A project team runs the tenant migration. Your job is the user: their devices, their apps, their habits and their tickets.
The map
Here it is as plain text, the way you might sketch it on a whiteboard:
GOOGLE WORKSPACE (source) MICROSOFT 365 (destination)
───────────────────────── ───────────────────────────
Gmail ──┐
Calendar ──┼─ Exchange Online migration ──▶ Exchange Online mailbox
Contacts ──┘ (batches in Exchange admin (Outlook: mail, calendar,
center > Migration) contacts)
My Drive ──┐ ┌─▶ OneDrive (personal files)
Shared drives ──┴─ Migration Manager ───────────┴─▶ SharePoint sites /
(Microsoft 365 Migration app Teams channel files
installed in Google Workspace)
Everything else (Chat, Sites, add-ons, browser sign-ins, phones)
──▶ no arrow on this map: handled by people, guides and tickets
The mail path: Microsoft's Google Workspace migration in Exchange Online moves mail, calendar and contacts in migration batches. Each batch syncs, shows "Synced", and is then completed.
The file path: Migration Manager moves Google Drive files, metadata and permissions to OneDrive and SharePoint. Two details matter later. File-level sharing only migrates if the project turns it on in permission settings, and older file versions need their own setting too.
The bottom row is where most week-one tickets come from. Neither tool's documentation lists Google Chat. Neither tool can touch the cached Google account in a user's Chrome profile, or the Gmail app on their phone.
Gotcha: Teams appears on the Microsoft side as the place where team files and conversations live. It is not a migration target for Google Chat history on this map. If a user asks where their Chat history went, that question belongs to the project, not to you.
What the user actually experiences
The mail move is staged: the project moves users in batches, and the public MX record moves once, at the end. Here is how Microsoft's own walkthrough describes it:
- Before: MX points to Google. The project creates two routing subdomains, one pointing to Google and one to Microsoft, and pre-creates every user in Microsoft 365 as a mail user.
- During a batch: the user still works in Gmail. Mail syncs across in the background.
- After their batch completes: Google forwards that user's new mail to their Microsoft 365 mailbox. The user should now work in Outlook. Colleagues in later batches are still in Gmail.
- After all batches: someone updates MX by hand to point to Microsoft 365, and the routing domains are removed.
At step 3, two people at the same desk can be on different systems. That one fact explains a large share of the confusion you'll see. Forwarding also depends on the Google tenant letting users set a forwarding address. If that is blocked by policy, forwarding fails.
Who owns what
| Project team owns | Support owns |
|---|---|
| The Microsoft 365 tenant and its tenant-wide settings | Users' laptops, phones and browser profiles |
| Migration batches (mail) and Migration Manager tasks (files) | Outlook, OneDrive, Teams and mobile app setup |
| MX, routing subdomains and other DNS changes | Tickets, triage and what users are told |
| Identity mapping and permission settings | Floor-walking and quick guides |
You may read the project's side to explain a ticket. A read-only check you can run on day one, from any Windows machine:
# Where does mail for the domain go right now? Read-only, no admin role needed.
Resolve-DnsName -Name contoso.com -Type MX | Select-Object NameExchange, Preference
# Example output mid-migration (MX still at Google):
# NameExchange Preference
# ------------ ----------
# smtp.google.com 1
If MX still points to Google but the user's batch has completed, their new mail reaches Outlook only through forwarding. That helps you read a "missing mail" ticket. Changing MX is never your fix.
This course is independent
This course is not made by or endorsed by Microsoft or Google, and it does not reproduce their documentation. That matters for a practical reason. Admin screens, roles, licences and limits change. For example, Microsoft now offers an entry point under Microsoft 365 admin center > Setup > Migration resources > Explore migration & imports tools > Google Workspace. It has also documented a simplified Migration Manager Lite, on by default for tenants with fewer than 300 licences. A screenshot from last year may show neither.
So keep a small verification register for every screen, role or limit you rely on:
# verification-register.yaml: one entry per thing you rely on
- item: "Migration Manager entry point via M365 admin center > Setup > Migration resources"
status: GA # GA | preview | unconfirmed
source: https://learn.microsoft.com/sharepointmigration/mm-google-overview
checked: 2026-11-03
- item: "Exchange Google Workspace migration moves mail, calendar, contacts"
status: GA
source: https://learn.microsoft.com/exchange/mailbox-migration/how-it-all-works-in-the-backend
checked: 2026-11-03
- item: "Migration Manager Lite default under 300 licences"
status: unconfirmed # documented, but confirm it applies to YOUR tenant
source: https://learn.microsoft.com/sharepointmigration/mm-google-overview
checked: 2026-11-03
Best practice: if a vendor page says "preview", write preview. If you can't find the page, write unconfirmed and don't promise users anything based on it.
Key takeaways
- Mail, calendar and contacts move through Exchange Online migration batches. Drive and shared drives move through Migration Manager to OneDrive and SharePoint.
- The mail move is staged: users in completed batches work in Outlook while MX still points to Google, and MX moves once at the end.
- The project owns the tenant, the batches and DNS. Support owns devices, apps, tickets and what users are told.
- Chat, cached browser sign-ins and phones have no migration arrow. Expect tickets there.
- The course is independent of both vendors. Mark everything you rely on as GA, preview or unconfirmed, with its source and the date you checked it.