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.
Your email moves on the agreed date, with every mailbox accounted for.
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.