How to structure a Microsoft 365 tenant migration
A practical operating model for moving from tenant discovery to waves, cutover, validation, and operational handover.
A strong migration plan connects business purpose to technical execution. Start by defining the event driving the move, the people authorized to make decisions, and the evidence required to call the work complete.
Build a fact base
Inventory tenants, identities, domains, workloads, data, owners, integrations, policies, deadlines, and known constraints. Record uncertainty instead of hiding it.
Separate workstreams, connect decisions
Exchange, Teams, OneDrive, and SharePoint have different migration objects and risks. Manage them as distinct workstreams, but connect them through shared identities, owners, waves, communications, and acceptance criteria.
Plan in waves
A wave should be more than a list of users. Include prerequisites, accountable owners, migration window, communications, validation, exception routes, and downstream support.
| Stage | Core output | Decision |
|---|---|---|
| Discover | Fact base and gaps | Is scope understood? |
| Design | Waves and controls | Is the plan executable? |
| Pilot | Observed evidence | What must change? |
| Execute | Migrated waves | Proceed, pause, or escalate? |
| Handover | Accepted service | Who owns operations? |
Define “done” before cutover
Technical completion is not the same as operational acceptance. Confirm user access, workload behavior, exceptions, communications, support ownership, and decommissioning decisions.