Migration
Google Workspace to Microsoft 365
Moving mail, files and calendars out of Google Workspace. The data transfer itself is well-trodden. What takes the time is everything without an exact equivalent on the other side. Microsoft 365 is not a second copy of your Google estate. It is a new identity and access model, and it has to be designed before anyone moves.
Most of these start with a licensing renewal, or with a decision to standardize after an acquisition.
What you receive
Five documents about the move, produced before it starts and yours to keep.
- Estate inventory
- Users, groups, shared drives, delegation, the calendar estate, and every third-party application authenticating against Google.
- Mapping decisions
- How the Google sharing model resolves into the Microsoft one — per shared drive and per permission type, agreed before anything moves rather than discovered during.
- Target-state design
- The Entra ID model, the access policies, and what takes over from the controls that live on the Google side today.
- Migration plan
- Waves, a cutover window, and the rollback position at each stage.
- Validation criteria
- What finished means, per wave, agreed in advance of the wave running.
What does not map cleanly
Five places where the two platforms have no exact equivalent, and each one is a decision rather than a setting.
- Shared drives are not document libraries
- A Google shared drive is a membership model. A SharePoint library is a permission model layered on a site. One is not a rename of the other, so the mapping is a decision per drive rather than a setting to carry across.
- Sharing is link-first
- Anyone-with-the-link has no exact equivalent under most Microsoft tenant configurations. Every such link is a decision: it survives as a scoped share, it is reissued, or it stops working. Somebody has to make that call before the files move.
- Delegation works differently
- Google delegation is granted per account. The Microsoft equivalent is a mailbox type with its own licensing and permission model, so delegated access is rebuilt rather than transferred.
- The calendar estate is usually the largest surprise
- Room and equipment resources, long recurring series with external attendees, and delegated calendars each behave differently on the other side. It is routinely more work than the mail.
- Applications authenticate against Google
- Anything using Google as its identity provider needs a new home before the Google tenant is switched off. These are the dependencies nobody has a list of, and they are why discovery precedes the plan.
Identity is being built, not merged
In a move between two Microsoft tenants, two identity models are reconciled against each other. Here there is only one, and it is on the side being left.
Everything on the Microsoft side is new: the directory, the groups, the access policies, the device posture. Nothing has to be inherited — and nothing can be assumed either, which is why the target design is an artifact rather than a by-product.
Both platforms are live at once
Mail routes between the two while people move in waves, and calendar availability is shared across the boundary so meetings can still be booked by people who have not moved yet.
Coexistence between Google and Microsoft is thinner than between two Microsoft tenants. That is a reason the migration plan matters more here, rather than a reason to move everyone at once.
How finished is decided
Per wave, against criteria agreed before that wave runs. Mail delivered and searchable. Files present, with their permissions resolved as designed. Calendars intact, and the applications that mattered still authenticating.
Fidelity gaps found after the fact are the common failure on this path. Validation is a defined step with named criteria for that reason — not a period of waiting to see whether anyone complains.
What happens next
A completed move of this kind, written up: moving a software company from Google Workspace
Questions people ask before committing
Do the sharing links in our documents keep working?
No — external sharing links are not recreated, and Microsoft says so plainly: after the migration they have to be set again at the destination.
This is the finding that surprises people most, because a link pasted into a contract, a ticket or an email years ago is not something anyone has a list of. Deciding which of them still matter is discovery work, not migration work.
What about the people outside the company we share with?
Content is not shared with external collaborators automatically, by design. Access for people outside the organization is re-established deliberately after the move rather than carried across with the files.
Does version history survive?
Yes. Version histories migrate with the files.
Can we tidy up the folder structure while we move?
No — rename or move something mid-migration and it is treated as a brand new object, so the whole subtree is copied again. Both the owner and everyone it is shared with end up with duplicates.
Restructuring happens before the move or after it, never during. It is a reasonable thing to want and an expensive thing to attempt at the wrong moment.
Is there anything that cannot come across at all?
Google Sites and Maps. Google does not permit their export, so no tool moves them and they have to be rebuilt or retired as a decision.
Content the account being migrated cannot itself open is also excluded. Files sitting in somebody else's personal drive move with that person, not with the team that uses them.
Published by Microsoft: Migration Manager Google FAQs
Know what does not map before you move it.
The mapping decisions are the engagement. Made in advance they are a design; made during a cutover they are a series of surprises with an audience.