Google Workspace to Microsoft 365: What Moves, Changes or Needs Rebuilding
Mail, files and collaboration behavior need separate acceptance checks. Use a source-to-target capability matrix and a pilot instead of assuming every tool preserves the same history, links and automation.
AZ / decision fieldnote
Moving content does not preserve every relationship.
An accepted Microsoft 365 destination
Content
Mail, calendars and files
Connections
Links, permissions and shared ownership
Behavior
Scripts, workflows and application integrations
Use this in your decision
Inventory the relationships around the content, then decide what to move, rebuild or retire.
- What is expected to survive the tool-driven move?
- Which links, permissions and workflows need separate work?
- How will users validate the replacement behavior?
Reading aid for this article. The analysis and supporting sources follow below.
A Google Workspace exit moves several workloads, not one homogeneous set of data. Mail, calendars, Drive content, permissions, links and business automations need separate decisions. Some content transfers; some changes format; some needs an agreed replacement or archive.
Use a capability matrix for the chosen tool
Microsoft documents separate routes for Google Workspace mail, calendar and contact migration and Drive migration through Migration Manager. Third-party tools may have different capabilities. Record the product/version, date and workload settings against each acceptance requirement.
| Workload | What to establish | Pilot evidence |
|---|---|---|
| Mail and labels | Mailbox scope, folder mapping, archives and exceptions | Counts, representative messages and shared access |
| Calendars and contacts | Supported fields, recurring events and delegation | Owner tests representative events and contacts |
| Google documents | Conversion behavior, formats, formulas and embedded content | Business owner opens and checks important files |
| Drive history and permissions | Tool-specific version coverage, ownership and permission mapping | Selected versions and allowed/denied access tested |
| Links and shortcuts | Which references can be translated or must change | Important links checked and exceptions assigned |
| Forms, Sites, scripts and integrations | Supported transfer, archive or separately scoped rebuild | Named process owner accepts the replacement or retained system |
Do not promise universal losses or universal preservation
“No tool can preserve history” and “everything moves cleanly” are both poor starting points. Verify the actual source item and chosen tool. A successful content copy also does not prove formulas, sharing behavior or a downstream automation still work.
Select samples that expose the awkward cases: a heavily revised document, a restricted shared drive, a recurring meeting, a spreadsheet with business formulas and a link embedded in an external system. Agree the acceptable destination behavior before the full migration.
Separate technical migration from business redesign
Moving files and correcting unsupported paths can be part of migration. Replacing an Apps Script process, redesigning approvals or rebuilding a site may be another project. Put those decisions in the scope instead of discovering them after the original system is retired.
Make handover a set of checks
- Source and destination inventory, with a named owner for each workload.
- Reconciliation results and a list of unresolved items.
- The accepted tool capability matrix and pilot results.
- A cutover window, rollback/stop criteria and user communication plan.
- An agreed retention or export decision for material that does not move.
Start with the email migration scope and file migration scope if those workloads are already understood. For interdependent workloads, multiple tenants or unclear ownership, a separate migration plan can establish the implementation scope.
About this article
Published by AZ Innovations, led by Alwatheq Zboun. We complete scoped Microsoft 365, security, migration and automation work. See who does the work or the delivered work.
Migrate email to Microsoft 365, with every mailbox checked.
Email is moved on the agreed date, mail is arriving and sending on the new path, and every mailbox is checked against the original list.