A Google Workspace to Microsoft 365 migration is not complete when Gmail messages appear in Outlook or when the MX record points at Microsoft.

The business has moved only when people can sign in, receive and send mail, find their calendars, open the files they need, work in correctly owned team spaces, collaborate with the right outsiders, and understand what still lives in Google. Until then, you have copied some data and changed a route.

Use a migration register that treats identity, mail, calendars, contacts, personal files, shared files, applications, devices, DNS, security and retirement as separate workstreams with one coordinated cutover.

Define “done” before selecting a tool

For each workload, record:

  • source owner and destination owner;
  • what is in scope and deliberately excluded;
  • source count, size and sharing shape;
  • destination service and container;
  • what fidelity is required for timestamps, versions, permissions, labels and links;
  • migration method and current product limitation;
  • pilot and batch order;
  • acceptance test and evidence owner;
  • rollback or coexistence decision; and
  • source retention and retirement date.

If the destination for a shared Drive is “someone’s OneDrive,” stop. Personal Drives usually map to a person’s OneDrive; shared Drives normally need a team-owned SharePoint site or another durable group-owned destination.

Inventory the dependencies people forget

Do not limit discovery to users and mailbox sizes. Inventory:

  • primary domains, aliases, groups and resource addresses;
  • suspended, archived, departed and shared identities;
  • Gmail routing rules, forwarding, journaling and compliance settings;
  • calendars, rooms, delegates and external sharing;
  • contacts and address lists;
  • personal Drives, shared Drives, shortcuts, externally owned files and externally shared links;
  • Google-native Docs, Sheets, Slides, Forms, Sites and Maps;
  • apps that use Sign in with Google, service accounts, SMTP relay, APIs or Google groups;
  • mobile devices, desktop mail profiles and sync clients;
  • retention, Vault, legal holds and backup; and
  • domain registration and DNS ownership.

The migration plan should identify what cannot be transferred automatically. Microsoft’s current Migration Manager guidance says external sharing links are not recreated and external collaborators are not automatically regranted access. Those are deliberate security boundaries, not small warnings to discover after cutover.

Build Microsoft 365 before moving data

Prepare the destination in an order that avoids both premature cutover and accidental service creation:

  1. verify tenant ownership, billing and the administrative break-glass design;
  2. add and verify the domain without directing production mail to Microsoft yet;
  3. create or synchronise users and groups with stable identity mapping;
  4. assign the licences required for the migration method and target workloads;
  5. configure MFA, Conditional Access or the selected small-business security baseline;
  6. create team-owned SharePoint destinations for shared content;
  7. confirm that personal OneDrive destinations are provisioned where the selected migration flow requires them;
  8. configure accepted domains, mail protection and connectors without weakening authentication; and
  9. prepare support, communications and a known-good rollback route.

Microsoft’s current small-business Google Identity Sync is a one-way method for preparing users and groups and is currently described for tenants with fewer than 300 licensed users. That makes it an option, not a universal design. Larger, hybrid or complex environments need an identity plan appropriate to their directory source.

Pilot the awkward users, not the easiest ones

A useful pilot includes several shapes:

  • an ordinary user with typical Gmail and Drive content;
  • a delegate or executive-assistant calendar pair;
  • a user with a large or deeply nested Drive;
  • a shared Drive with groups, external collaborators and Google-native files;
  • a mobile-heavy user;
  • an application or device that relays mail; and
  • a departed, suspended or archive-only identity.

The pilot must test the method and the acceptance process. A green migration dashboard is not enough.

Scan before copying Google Drive

Migration Manager requires Google Drive tasks to be scanned before migration. Review the detailed reports, not only the ready status.

Microsoft currently advises that one Drive migration task should not exceed 100,000 items or 1 TB. Split larger Drives into folder-based tasks so a single oversized user does not become an opaque, long-running exception.

Before each batch, confirm:

  • source paths and destination paths;
  • personal versus shared ownership;
  • user, group and guest identity mappings;
  • unsupported or unconvertible items;
  • invalid names and destination path limits;
  • external shares and links that need a deliberate replacement;
  • version-history requirements;
  • Google Forms destinations where applicable; and
  • the notification and report-retention plan.

Migration Manager copies accessible content. It does not remove the Google original. That is useful for rollback, but it means source cleanup is a separate decision.

Move mail as a controlled routing change

Mail migration and mail routing are related but not identical.

Pre-stage data while Google remains authoritative where the method supports it. Keep a record of the last successful synchronisation. Before changing DNS, reduce uncertainty around TTLs, accepted domains, aliases, groups, forwarding, SMTP relay and applications.

At cutover:

  1. freeze changes that would invalidate identity or routing mappings;
  2. run the planned final or delta migration;
  3. change the approved DNS records;
  4. verify inbound and outbound mail with independent external systems;
  5. test internal delivery, aliases, groups, calendar invitations, replies to old messages and expected authentication results;
  6. confirm application and device relay separately; and
  7. watch both Google and Microsoft queues during coexistence.

Do not weaken SPF, DKIM, DMARC, TLS or relay restrictions to make a failing test turn green. Diagnose the sender, connector, authentication result and reply code.

Validate what people actually use

For every pilot and production batch, sample:

  • oldest, newest, large and attachment-heavy mail;
  • folders or labels with unusual nesting;
  • recurring meetings, exceptions, rooms and delegates;
  • personal contacts and group membership;
  • ordinary Microsoft-format files and converted Google-native documents;
  • deeply nested folders and large items;
  • version history where it is required;
  • internal, group and external permissions;
  • personal Drive ownership and shared-Drive destination ownership;
  • desktop, browser and mobile sign-in; and
  • links in business processes, intranets and documentation.

Count comparison is necessary but not sufficient. Ten thousand copied files are not useful if the owner cannot find them, critical Google Sheets lost behaviour, or external suppliers no longer have an approved way to collaborate.

Separate exceptions from the main cutover

Do not leave failures scattered across chat and migration dashboards. Give every exception:

  • source object;
  • destination object;
  • error or limitation;
  • business impact;
  • owner;
  • chosen treatment—retry, transform, retain, recreate or retire;
  • evidence; and
  • deadline.

This lets the majority of users complete without declaring difficult data “close enough” or holding the whole migration open indefinitely.

Retire Google only after acceptance

Keep the source available for the agreed coexistence and verification window. Then decide, separately:

  • what Google data remains for legal, tax, contractual or recovery purposes;
  • whether Vault, exports or independent backups are required;
  • which subscriptions can be reduced or cancelled;
  • which OAuth apps, API clients and service accounts must be removed;
  • when mail routing and domain aliases can be simplified;
  • who confirms that Google-managed DNS or domain registration remains accessible; and
  • how support will handle late-found links or data.

Do not delete accounts or cancel the subscription because the first day looks quiet. Do not keep two writable systems indefinitely either. Name the end of coexistence and the evidence required to reach it.

The handover pack

A completed migration leaves behind:

  • the final user, group and workload map;
  • source and destination counts with explained differences;
  • migration and exception reports;
  • DNS before-and-after records;
  • mail-flow and authentication evidence;
  • file, permission, version and Google-native conversion samples;
  • application and device changes;
  • open exceptions and owners;
  • source retention or deletion decisions;
  • administrator and migration-app access removal; and
  • user-facing guidance for new sign-in, Outlook, OneDrive, Teams and support.

The best migration is boring because the decisions were made before the pressure of cutover. The tool copies data. The plan preserves ownership, access and trust.