SAMPLE-MIG-01 · FICTIONAL DATE 2026-01-12
Example Workshop · M365 to Google Workspace planning
Status: Fictional planning-format sample · Source: source.example.test · Destination: destination.example.test · Approval: none. Reserved example.test names are not real tenants.
Purpose and boundary
Illustrate how an operator could organize a readiness discussion for one explicitly named source, destination and selected workload set. This sample assumes no inventory was supplied. Every item below is a question or proposed gate, not a finding about either environment.
| Workload | Planning question | Evidence / owner | Status |
|---|---|---|---|
| Mail and calendar | Which item types, shared resources, archive states, aliases and coexistence needs are in scope? | Customer-selected minimized inventory; workload owner TBD | Not assessed |
| Files and collaboration | Which sites, drives, permissions, links and sharing rules are included or excluded? | Customer-selected inventory and data owner TBD | Not assessed |
| Identity and domains | How will sign-in, groups, aliases, service identities and domain verification be handled? | Identity owner and domain administrator TBD | Not assessed |
| Devices and applications | Which clients, mobile devices, integrations and retention obligations depend on the current platform? | Customer application / endpoint owners TBD | Not assessed |
Readiness gates
- Confirm authority and scope. Name source and destination owners, selected object classes, exclusions, residency constraints, and the authorized evidence channel. No access or collection is authorized by this sample.
- Resolve prerequisites. Confirm licensing, administrator roles, vendor-supported workloads, quotas, domain ownership, identity mapping, retention, security controls, and coexistence requirements with the responsible owners.
- Review collisions and exceptions. Have named owners resolve duplicate addresses, aliases, groups, privileged/service identities, unsupported objects, permissions, archives and hold requirements. Inventory parsing alone cannot decide these.
- Approve a pilot separately. Choose a customer-authorized representative test set, define source/destination reconciliation checks and stop criteria, and record who may approve any live migration action.
Illustrative phase plan
| Phase | Exit evidence | Decision owner | State |
|---|---|---|---|
| Discovery | Accepted scope, exclusions, dependency and responsibility register | Customer sponsor + delivery owner | Proposed only |
| Readiness | Reviewed mapping exceptions, licensing and vendor-tool confirmation | Workload and identity owners | Blocked on evidence |
| Pilot | Written pilot approval, test cases, reconciliation and rollback decision | Change authority | Not authorized |
| Cutover | Approved change record, confirmed window, communications and stop/rollback thresholds | Customer change authority | Not authorized |
| Closeout | Accepted outcome, unresolved exceptions, support owner, retention/deletion record | Named customer owner | Not started |
Dates and durations: intentionally unset. No duration or availability can be inferred before evidence review, vendor confirmation, capacity review and an accepted written quote.
Cutover and rollback questions
- What customer-owned backup or recoverable source state is verified before each separately approved change?
- Which observable condition stops a wave, who decides, and how are users told?
- Who may choose rollback, what source remains authoritative during transition, and which steps are reversible?
- How are mail flow, sign-in, selected file access, calendar behavior and agreed application dependencies verified by their owners?
- What remains unresolved at handoff, who owns it, and when will evidence be removed under the accepted retention plan?
Decision register
| Decision | Owner | Current state | Gate |
|---|---|---|---|
| Confirm workloads, exclusions and source of truth | Fictional customer sponsor | Open | Before quoting a final plan |
| Select and license migration tooling | Fictional technical owners | Open | Independent compatibility and security review |
| Approve pilot or production work | Fictional change authority | Not approved | Separate written scope and action approval |
Sample acceptance criteria for a future scoped plan
A customer could accept a planning deliverable when it names the agreed environments and workloads, lists assumptions and exclusions, identifies unresolved decisions and responsible owners, records proposed pilot checks and stop conditions, and distinguishes every unapproved execution step. These are example criteria only; actual acceptance must be agreed in the customer-specific written scope.
Limitations
This is not an assessment, compatibility statement, migration tool, schedule, quotation or statement of work. No M365 or Google API connection exists in this sample; no Graph or Google permissions are requested; no tenant-wide export, data copy, DNS change, identity change, cutover, rollback test or post-migration support was performed. A completed planning document would not authorize execution. Keep customer exports, credentials and reports outside this repository.