Worked example · illustrative

Worked example: an 80-person design agency moves from Google Workspace to Microsoft 365

A fictional design agency follows our Google Workspace to Microsoft 365 playbook: mail in Exchange Online batches, My Drive to OneDrive and shared drives to SharePoint with Migration Manager, MX changed last. The organisation is invented to show how the steps fit together.

The scenario

Who they are and what they faced

Illustrative example. The organisation is fictional; the steps follow our How to migrate from Google Workspace to Microsoft 365.

Organisation

An 80-person design agency with two studios and many remote staff (fictional)

Moving from → to

Google Workspace: Gmail, Calendar, Contacts, My Drive, a shared drive per client team, a few Google Sites, Apps Script automations in Sheets and several apps that use Sign in with Google → Microsoft 365: Exchange Online, OneDrive, SharePoint sites connected to Teams, and Microsoft Entra ID single sign-on for third-party apps

Constraints

  • Client project files are large design assets, and studios cannot lose access to them during deadlines
  • Several clients have been given access to shared drive folders as guests
  • The Google Workspace renewal date is fixed, and the agency wants as little overlap as practical
  • Staff use phones heavily for mail and calendar
Phase: Assess

Assess

The IT lead opened the consolidated Google migration dashboard from the migration page in the Microsoft 365 admin center, as the plan step of the playbook describes. With 80 source mailboxes the dashboard pointed the Mail tile at Simplified Gmail migration, and with fewer than 300 Microsoft 365 licences Migration Manager would open in its Lite wizard.

The Google Admin console storage figures showed a handful of very large drives, mostly old exports and render files. The inventory also listed shared drives with duplicate names and two with slashes in the name, Google Sites used as a studio intranet, Apps Script projects bound to finance Sheets, Google Chat spaces, shared calendars and room resources, and every app under API controls that used Sign in with Google.

Decisions

  • Use the classic Exchange admin center batch path for mail The playbook says the classic path gives more control over batches. The agency wanted to complete mail per studio, in step with the Drive waves, and accepted the extra set-up of routing subdomains and mail users.
  • Use Migration Manager for Drive and shared drives The playbook recommends Microsoft's native file tool. The agency did not need Google Chat history moved, which is the main reason the playbook gives for choosing a third-party platform.
  • Delete or archive before scanning The playbook's first consideration is to decide what not to move. Owners cleared old exports and renders in Google before the first scan.

How to run this phase →

Phase: Plan

Plan

The plan ran in this order: routing domains and mail users, a pilot of the IT lead and two volunteers, Drive first passes per studio, mail batches per studio, then a single MX change once every batch had synced. Google licences were kept until mail stopped arriving in Gmail, so the overlap with the renewal date was planned from the start.

The risk register held the playbook's known problems: missing items if retention policies ran during the copy, routing failing between the two subdomains, Apps Script processes stopping in finance, and guests losing access to client folders.

Decisions

  • Announce a folder structure freeze from first pass to final delta The playbook warns not to restructure folders between passes. Designers were asked to tidy up in Google before the first scan or in SharePoint after cutover.
  • Give every item the tools skip an owner and a date Sites, Apps Script, shared calendars, rooms, vacation responders and external sharing links all went on the runsheet with a named owner, as the playbook advises.

How to run this phase →

Phase: Design

Design

The Identity and licence mapping sheet mapped each Google account to a Microsoft 365 user and plan, chosen by the features each group used rather than by Google edition names. Each client team's shared drive was mapped to its own Teams-connected SharePoint site, with the drive landing in a folder rather than the library root, because the playbook says root folder permissions are not migrated to a library root.

The DNS worksheet recorded two routing subdomains: o365.contoso.com pointing at Microsoft 365 and gsuite.contoso.com with Google's MX record. File-level permissions were turned on only for the shared drives where files had been shared one by one, and older versions were limited to what designers actually used.

Decisions

  • Set site owners explicitly Shared drive Managers map to Can edit, not owner, so each studio lead was added as a Teams owner with Add-TeamUser.
  • Rebuild the studio intranet as a SharePoint communication site The playbook lists Google Sites as something that does not move. The agency rebuilt it rather than looking for a converter.
  • Move Sign in with Google apps to Entra ID single sign-on before closing accounts The playbook says these apps must move before the Google accounts close, or users lose access to them.

How to run this phase →

Phase: Execute

Execute

The IT lead added the two routing subdomains in Google and Microsoft 365, allowed automatic forwarding to the Google routing domain with a remote domain in Exchange Online, allowed SMTP forwarding for the migrating organisational unit in Google, and created a mail user for every person with New-MailUser. The Exchange admin center created the Google project and service account key, the client ID and scopes were authorised in the Google Admin console, and the migration endpoint was created from the JSON key.

OneDrive was pre-provisioned with Request-SPOPersonalSite. Migration Manager was connected through the Microsoft 365 Migration app from Google Workspace Marketplace, identities were mapped, and first passes ran per studio. Duplicate and slashed shared drive names were fixed in Google before scanning. Mail batches started from CSVs, migrating mailboxes were placed on retention hold, and licences were assigned the same day each batch started.

Decisions

  • Keep migrating users out of group-based licensing until their batch started The playbook says starting the batch converts mail users to mailboxes and licences should follow then, within Microsoft's 30 days.
  • Allow for files that report as 1 byte Older Google files showed a size of 1 byte in the scan report. The playbook treats scan totals as a minimum, so storage and wave time were planned with a margin.

How to run this phase →

Phase: Cut over

Cutover

The MX TTL was lowered a day ahead. Each mail batch was completed when it reached Synced, which ran a final sync and set Google to forward new mail to Microsoft 365. When every batch was complete and the final Drive deltas had run, the IT lead replaced the Google MX records with the Microsoft 365 value, updated SPF while leaving Google in it until Google stopped sending, and set up DKIM for Exchange Online.

Google licences and forwarding stayed in place through propagation. The IT lead searched Email Log Search in the Google Admin console until no new inbound mail appeared, then removed the completed batches, the migration endpoint and the routing subdomains.

Decisions

  • Change MX last The playbook says MX changes only after every batch has synced, so mail for users still in Gmail keeps flowing through the routing addresses.
  • Record every DNS change before making it Old and new values went into the DNS cutover record sheet so MX could be restored to smtp.google.com quickly if the rollback trigger was hit.

How to run this phase →

Phase: Close

Close

Validation followed the playbook: every mail batch user Completed with only expected skipped items, labels showing as folders, every Drive and shared drive task Completed with only known gaps, site owners correct, MX, SPF, DKIM and DMARC passing, every Sign in with Google app now signing in through Entra ID, and rooms and shared calendars recreated.

Before closing Google accounts, the agency exported the Chat history it had to keep with Google Vault. Client folder owners reshared with guests from SharePoint. Retention hold was released after verification and the dates recorded. Google licences were removed only after the logs showed no new mail.

Decisions

  • Treat removing Google licences as the point of no return The playbook says Migration Manager never deletes Google files, so the real point of no return is removing Google licences, routing domains or the account.

How to run this phase →

Cutover

The cutover timeline

  1. Two weeks before
    Routing subdomains verified on both sides; mail users created; Google project and endpoint in place; pilot batch completed.
  2. One week before
    First Drive and shared drive passes complete per studio. Quick-start guide sent to staff.
  3. Day before, morning
    Lower the MX TTL. Confirm every mail batch is Synced.
  4. Cutover day 17:00
    Folder freeze starts. Run the final Drive and shared drive deltas.
  5. Cutover day 18:00
    Complete remaining mail batches. Confirm Google forwarding to o365.contoso.com is set for each user.
  6. Cutover day 19:00
    Replace Google MX records with the Microsoft 365 value. Update SPF and set up DKIM.
  7. Cutover day 19:30
    Send external test messages to several staff; check delivery in Outlook and on phones.
  8. Next morning
    Floor and remote support: staff add the Microsoft 365 account on phones, remove Google Drive for desktop once OneDrive syncs, and review migrated rules.
  9. Following days
    Watch Email Log Search in Google until no new inbound mail arrives, then remove batches, endpoint and routing subdomains.
Lessons

What surprised them and what they did

Verification flagged missing items for some mailboxes

A default retention policy had moved items during the copy. The team disabled MRM and archive policies for migrating users, as the playbook's errors table says, and re-enabled them after the move.

Two shared drives did not appear in Migration Manager

One shared a name with another drive and one had a slash in its name. They were renamed in Google and rescanned, as the playbook describes.

Gmail filters arrived turned off

The playbook warns filters arrive as Outlook rules that are turned off. The quick-start guide told staff to review and turn on the rules they need.

Clients lost access to shared folders

External sharing links do not move. Folder owners had a date on the runsheet to reshare with guests from SharePoint.

A finance Sheet stopped updating

Its Apps Script did not run in Excel. The owner had listed it earlier, so its replacement was ready to switch on.

Templates

Templates they used

FAQ

Questions

Is this a real agency?

No. The agency is fictional. It shows how the steps in our Google Workspace to Microsoft 365 playbook fit together.

Why not use Simplified Gmail migration with only 80 users?

It was offered, and the playbook lists it as the low-effort path for smaller tenants. This agency chose the classic batch path for more control over when each studio completed. Either is consistent with the playbook.

What did not move automatically?

Google Sites, Chat history, shared calendars, room bookings, vacation responders, Drive shortcuts and external sharing links, as the playbook lists.

When could they roll back?

Until Google licences, routing domains or the account were removed. Before that, MX can go back to Google and users can return to Gmail and Drive.

Do Google Docs stay as Google files?

No. Docs, Sheets and Slides become .docx, .xlsx and .pptx files in OneDrive and SharePoint.