Moving a software company from Google Workspace to Microsoft 365

The situation

A software company of a few hundred people ran on Google Workspace and moved to Microsoft 365.

Two things made it more than a mailbox move. The Drive estate had accumulated years of per-file sharing decisions, each one made by whoever owned the file at the time, with no model underneath them. And the roles people held in Workspace had no clean equivalent on the other side. The two platforms do not describe administrative access in the same terms, so there is no mapping to copy.

So the question was never whether the data would arrive. It was whether, once it had, anyone could say who could reach what, and why.

What was actually done

Access was rebuilt from what people already held

Each role was mapped to its prior equivalent rather than granted fresh in the new tenant. The starting position was what a person could already reach, not what somebody assumed they needed — which is the difference between a migration and a re-provisioning exercise nobody scoped.

The SharePoint structure was designed, not mirrored

A flat Drive does not become an information architecture by being copied into one. Sites, libraries and the boundaries between them were decided before content moved.

Content was triaged before it moved

Some of the estate moved, some was archived, and some was deliberately left behind. Moving everything is the cheaper decision to make and the more expensive one to live with.

The migration ran in passes

Rather than as a single operation, with each pass checked before the next one started.

Access was audited after the move, not assumed

Once people were working in the new tenant, what they could reach was checked against what they were supposed to reach. The result was written down rather than asserted.

What the client received

• A documented permission model for the new tenant, rather than an inherited one
• A record of what moved, what was archived and what was left behind, with the reason in each case
• The SharePoint structure as designed, and the decisions behind it
• The post-migration access review and what it found

What surfaced along the way

What went wrong on this engagement went wrong at the tooling and at the boundary between two platforms, rather than in the design. Every item below was resolved by deciding a mapping in advance or by re-running a pass.

• Throttling set the pace. Google’s API limits decide how fast a migration of this size can read the source. The schedule follows the rate the source will answer, and a plan built on the tooling’s throughput rather than the platform’s limits is a plan nobody can hold.
• Labels are not folders. A Gmail message carrying three labels has three possible places in a folder tree. The mapping is a decision — made deliberately before a pass runs, or discovered in the shape of somebody’s mailbox afterwards.
• Calendars behave nothing like mail. Recurring events with individual exceptions, room and resource bookings, and shared-calendar permissions are each their own migration. They are also the items a user notices first, because a calendar is what their week looks like.
• Authorization expires mid-migration. OAuth tokens have a lifetime shorter than a large migration. A long pass re-authorizes partway through, and a pass that stopped for that reason looks identical to one that failed until somebody checks which.
• Re-running a pass is how items arrive twice. Re-running is how the last few percent of a mailbox gets moved, and it is also how the same item lands twice. Both are true at once, which is why the passes are checked rather than repeated until the error count reaches zero.

These are ordinary for this platform pair, which is the useful thing about them. A migration plan that has budgeted for them absorbs them; one that has not treats each as a surprise and spends the schedule on it.