How to migrate Google Workspace to Microsoft 365

A Google Workspace to Microsoft 365 migration is four moves in a fixed order: identity, mail, files, then everything that quietly depended on the old system. The technical work is well understood and largely tool-driven. What goes wrong is almost always scope — the shared drive nobody mentioned, the calendar resource that belongs to a departed employee, the script that posts to a Google Sheet every night.

This is the sequence we use on live migrations, the audit that has to happen before any of it, and the four issues that account for most cutover weekends running long.

Audit before you plan anything

Migration tooling will happily move what you point it at. It cannot tell you what you forgot. Two days of audit up front reliably saves more than that later, and it is the step most often skipped because it produces no visible progress.

Establish, in writing:

• Account inventory. Active users, suspended accounts, aliases, delegated mailboxes, and shared or role accounts. Suspended accounts still hold mail somebody may need.
• Data volume per mailbox and per drive. This determines how long the transfer takes and whether it fits the window you have. A handful of 90GB mailboxes changes the plan.
• Shared drives and their owners. Google shared drives have no natural equivalent — they map to SharePoint sites or Teams, and that mapping is a business decision, not a technical one.
• External sharing. Every file shared with someone outside the organisation, and every "anyone with the link". These do not survive migration as-is, and the ones that matter need re-establishing deliberately.
• Third-party integrations. Anything authenticating against Google — single sign-on, backup tools, CRM connectors, automation scripts. This is the list that generates the surprises.
• Groups and mailing lists. Google Groups do several jobs at once; each maps to a different Microsoft 365 object depending on what it is actually used for.

Publish the inventory and have the business confirm it. The purpose is not accuracy for its own sake — it is to surface the systems nobody in IT knew about, which only the people using them can tell you.

Step one: identity, before any data moves

Identity comes first because everything else authenticates against it. Get this wrong and every subsequent step inherits the problem, and the tenant hardening you will want afterwards becomes far harder — the controls worth reviewing are set out in our Microsoft 365 security review.

• Create the tenant and verify the domain. Verification is a DNS record and can be done well ahead of any cutover — it changes nothing about where mail is delivered.
• Decide where the source of truth lives. If there is an on-premises Active Directory, Entra Connect syncs from it. If Google was the identity provider, users are created directly in Entra ID and Google's role ends at cutover.
• Match usernames deliberately. Mismatches between the Google primary address and the Microsoft 365 user principal name cause mail routing problems that are tedious to unpick afterwards.
• Set up multi-factor authentication and conditional access before users arrive, not after. Retrofitting MFA onto a population that has just been through a migration is two disruptions where one would do.

Licence assignment is worth a moment's thought here too. Assigning by group rather than per user means a leaver or joiner is one membership change rather than a manual step somebody forgets.

Step two: mail

Mail migration is the most visible part and, done properly, the least eventful. The standard approach is a staged sync:

1. Pre-stage. Run a full copy of every mailbox while users continue working in Google. This is the long part — it can run for days, and nobody notices.
2. Delta syncs. Repeat passes copy only what changed. Each is much faster than the first.
3. Cutover. Change the MX record so new mail is delivered to Microsoft 365. Run a final delta immediately afterwards to collect anything that landed in Google during propagation.
4. Dual delivery, briefly. Keep Google forwarding to Microsoft 365 for a week or two. It costs nothing and catches the senders who cached the old routing.

Lower the MX time-to-live to five minutes at least 24 hours before cutover. This single step is the difference between mail redirecting in minutes and trickling in over a day, and it has to be done in advance because the change itself has to propagate first.

Two things that do not migrate cleanly and should be communicated rather than discovered: Google labels become folders, and because a message can carry several labels but live in one folder, multi-labelled mail is duplicated or placed in the first label. And Gmail's filters do not convert to Outlook rules — users recreate the handful they actually rely on, which in practice is two or three each.

Step three: files

File migration is where the mapping decisions are made, and they are worth making explicitly rather than accepting a tool's defaults.

Native Google files convert on the way across. Straightforward documents come through faithfully. Complex spreadsheets — pivot tables, scripts, heavy conditional formatting — do not, and neither do Apps Script automations, which have no equivalent at all and need rebuilding in Power Automate or accepting as lost. Identify these during the audit and treat each as its own small project.

The shared drive to SharePoint mapping deserves a proper conversation with each owning team. A shared drive that is a document archive belongs in a SharePoint document library. One that is an active collaboration space belongs in a Team. Choosing wrongly is recoverable but annoying, and it sets the permissions model for years.

Step four: everything that depended on Google

This is the step that overruns, because it is the one nobody scoped. Work through it during the audit rather than on cutover weekend:

• Applications using Google as their identity provider. Each needs repointing at Entra ID, and each has its own process. Start early — some involve a vendor.
• Calendar resources. Meeting rooms and equipment become Microsoft 365 room mailboxes with their own booking policies, which are worth setting deliberately rather than accepting defaults.
• Google Sites, Forms, and anything embedded in an intranet. Usually rebuilt rather than migrated.
• Scripts and integrations. The nightly job writing to a Sheet, the form feeding a spreadsheet, the reporting tool reading a Drive folder. These fail silently after cutover, which is the worst way to find them.
• Mobile device management. If devices were enrolled through Google, they need re-enrolling in Intune, and that is a user-facing change requiring its own communication — see our end-user mobility and security work.

The four problems that cause most cutover trouble

Across migrations, the same four issues recur:

1. MX time-to-live left at the default. Mail arrives at the old system for hours after cutover. Entirely preventable, and only preventable in advance.
2. Shared drives nobody claimed. Migration stalls waiting for a decision about a drive whose owner left last year. Force ownership during the audit; an unclaimed drive gets archived rather than migrated.
3. External sharing assumed to carry over. A client cannot open the file they were working in on Monday morning. Produce the list of external shares that matter and re-establish them deliberately.
4. No plan for the first three days. The technical migration succeeds and the service desk is overwhelmed by people who cannot find their mail folders. Floor-walking support and a one-page "where things moved to" guide cost very little and remove most of it.

How long it takes

For a typical mid-sized organisation, allow four to eight weeks end to end. Roughly: one week of audit and planning, one to two weeks of tenant build and identity, two to three weeks of data pre-staging running in the background, a cutover weekend, and two weeks of aftercare.

Data volume affects the pre-staging window but not much else, because it runs while people carry on working. What actually drives the timeline is the number of integrations and the speed at which the business makes its mapping decisions — which is why the audit is the highest-leverage part of the whole project.

Conclusion

The migration itself is a solved problem with mature tooling. The risk sits in what was never inventoried: the shared drive with no owner, the script writing to a spreadsheet, the client who has been working from a shared link for two years.

Spend the time on the audit, sequence identity before data, lower the MX time-to-live a day ahead, and plan the first three days after cutover as carefully as the cutover itself. If Copilot is on the roadmap afterwards, the sharing decisions you make during migration are the ones that determine what it can surface later. Do that and the weekend is uneventful, which is exactly what a successful migration looks like.

Frequently asked questions

How long does a Google Workspace to Microsoft 365 migration take?

Four to eight weeks end to end for a typical mid-sized organisation: about a week of audit and planning, one to two weeks of tenant and identity build, two to three weeks of data pre-staging running in the background while people carry on working, a cutover weekend, and two weeks of aftercare. Data volume mostly affects the pre-staging window; what really drives the timeline is the number of third-party integrations and how quickly the business makes its shared-drive mapping decisions.

Will we lose email during the cutover?

No, provided the MX time-to-live is lowered to around five minutes at least 24 hours beforehand and dual delivery is kept in place for a week or two afterwards. Mail sent during DNS propagation is delivered to whichever system the sender resolved, and the final delta sync plus forwarding collects it. Leaving the time-to-live at its default is the single most common cause of mail trickling in for hours after a cutover.

Do Google Docs convert properly to Word and Excel?

Straightforward documents convert faithfully. Complex spreadsheets — pivot tables, heavy conditional formatting, anything driven by Apps Script — do not, and Apps Script automations have no equivalent and must be rebuilt in Power Automate or retired. Identify these during the audit and treat each as its own piece of work rather than expecting the migration tool to handle it.

What happens to Google shared drives?

They become SharePoint sites or Teams, and which one is a business decision rather than a technical default. A shared drive used as a document archive belongs in a SharePoint document library; one used as an active collaboration space belongs in a Team. Have the owning team decide, and force ownership of any unclaimed drive during the audit — waiting on that decision at cutover is a common cause of overrun.

Do Gmail filters and labels survive the migration?

Not directly. Labels become folders, and because a message can carry several labels but live in only one folder, multi-labelled mail is either duplicated or filed under the first label. Gmail filters do not convert to Outlook rules at all. In practice most users rely on two or three rules each and recreate them in minutes — but it should be communicated in advance rather than discovered on the Monday.

Should we set up MFA before or after the migration?

Before. Configure multi-factor authentication and conditional access while the tenant is being built, so users encounter the new sign-in experience once rather than being asked to change how they log in a second time a few weeks after a disruptive move.