The important distinction is shared data. The listing names Microsoft 365 Groups, SharePoint sites, group mailboxes, and Teams teams and channels alongside personal mailboxes, OneDrive accounts, Teams chats, and meetings. Microsoft’s existing migration-orchestrator documentation explicitly excludes shared Teams and SharePoint content from its User Data Migration solution. The roadmap therefore points toward a broader migration offering—not simply a new label for the current workflow.
For administrators planning a merger, divestiture, or tenant consolidation, that difference deserves attention. It does not, however, turn a roadmap estimate into a safe cutover date.
What the roadmap promises—and what it does not
The listing divides Cross-Tenant Orchestrated Migration into two categories:
| Migration category | Data named in the roadmap |
|---|---|
| User Data Migration—UDM | User mailboxes, OneDrive accounts, Teams chats, and Teams meetings |
| Shared Data Migration—SDM | Microsoft 365 Groups, SharePoint sites, group mailboxes, and teams and channels |
Its product designation is Microsoft 365 admin center, with Desktop and Web listed as platforms. The cloud designation is Worldwide (Standard Multi-Tenant), and the release phase is General Availability. Those fields describe the intended delivery scope; they do not override the separate In development status.
December 2026 should consequently be treated as an estimated release window. Microsoft’s roadmap explicitly warns that dates and descriptions can change, and that entries may disappear when capabilities become generally available, are postponed, or are cancelled.
The listing’s additional-information field is still TBD. It does not establish an admin-center navigation path, detailed SDM prerequisites, shared-data licensing, rollback behavior, or supported limits. Nor does its Desktop designation identify a required Windows build or introduce a Windows update to install.
The useful reading is narrow: Microsoft is signaling broader cross-tenant data orchestration through an admin-center product entry. It has not supplied enough detail in that entry to write a production deployment runbook.
Why shared data is the meaningful expansion
Microsoft Learn’s orchestrator overview, updated October 28, 2026, describes four supported user workloads: Exchange mailboxes, OneDrive accounts, Teams chats, and Teams meetings. It separately states that shared data—including Teams teams and channels and SharePoint sites—remains in the source tenant under the documented UDM solution.
That boundary matters because moving an employee’s personal content is not the same thing as moving the collaboration environment around them.
Consider a department being separated into another organization. Its employees may need their mailboxes and personal files, but they also need access to the department’s shared resources. As a planning inference, orchestration that covers both categories could reduce the separation between the user-migration workstream and the shared-content workstream. The roadmap does not yet establish how Microsoft will coordinate those operations.
There is also an important documentation trap. Microsoft Graph’s cross-tenant migration overview mentions user or group jobs and lists Exchange, Teams, OneDrive, and SharePoint workloads. Nevertheless, its explicit API-status section says user data migration only. Broad wording elsewhere on that page should not be treated as proof that every SDM resource in roadmap item 576273 has shipped.
For now, the distinction is straightforward: the roadmap names the expanded destination; the existing UDM documentation defines what administrators can safely assume about that documented workflow.
Orchestration coordinates content, not identities
Microsoft describes the existing orchestrator as a content-migration service. Customers remain responsible for creating and correctly configuring destination users. The service transfers supported content between those prepared source and target locations; it does not take over the entire identity transition.
That is a critical boundary for project owners. A successful content transfer should not be used as shorthand for “the tenant migration is finished.” Identity preparation must remain an explicit part of the plan.
The orchestration itself addresses workload dependencies. Microsoft recommends placing the selected user workloads together in the same migration batch when moving multiple workloads, rather than independently managing a batch for each service. Teams meeting migration has a particularly important dependency: selecting meetings without also selecting Teams chats and mailboxes prevents the batch from starting. Meeting migration also depends on successful mailbox migration.
In other words, orchestration is useful because the workloads are connected. It is not permission to ignore those connections.
The same caution applies to the future admin-center experience. Its appearance in the roadmap does not establish that prerequisites disappear, that identity mapping becomes automatic, or that every workload can be moved independently.
A scheduled cutover is not a completion guarantee
The documented UDM orchestrator supports a CompleteAfterDate. Despite the reassuring name, administrators should not interpret it as a promise that all migration work will be finished at that moment.
Microsoft explains that Exchange synchronization can happen beforehand. Once the scheduled time passes, the remaining selected workloads begin processing according to the migration flow. In its four-workload example, the mailbox cuts over after synchronization completes, and OneDrive, Teams chats, and Teams meetings then begin their migration work. If a batch contains only OneDrive and Teams chats, those workloads do not synchronize in advance merely because the batch was created early.
The practical consequence is a communication issue as much as a technical one. Tell users when disruption may begin, rather than describing the scheduling field as an all-services-ready deadline.
Microsoft also states that these migrations have no service-level agreement for completion. Duration depends on the users, associated content, and overall traffic. Planning should therefore distinguish three things: the scheduled transition point, the actual completion of each workload, and the time needed to verify the user experience.
That distinction is worth preserving even if the future admin-center interface makes batch creation easier. A friendlier dashboard cannot make data movement instantaneous.
What happens to the source data
The existing UDM documentation describes different outcomes for different workloads. Administrators should resist the tempting assumption that “migration” means either “everything is copied” or “everything is deleted.”
Exchange mailboxes
Microsoft says only user-visible mailbox content migrates: email, contacts, calendar items, tasks, and notes. Following a successful move, the source mailbox is deleted and is no longer available, discoverable, or accessible in the original tenant. The source user becomes a MailUser with routing information pointing toward the destination.
Mailboxes under any type of hold are blocked from migration. That is a reason to involve the appropriate compliance owners—not a reason to casually remove a hold to make a batch pass.
OneDrive
OneDrive content moves to the destination, with a redirect left at the source. Microsoft explicitly says incremental and delta migration passes cannot be performed in this workflow. Administrators should not build a plan around an assumed second pass that sweeps up later changes.
Teams chats and meetings
Original Teams content remains in the source, potentially in an edited form. Participant lists can change, and duplicate threads may exist across the tenants. Microsoft directs migrated users to use their target identity in Teams; accessing out-of-scope source content may still require a licensed source account.
These behaviors describe existing UDM, not the proposed SDM implementation. They cannot establish whether shared sites, groups, or channels will follow equivalent retention, redirection, or deletion rules.
A practical preparation sequence for administrators
There is not yet enough evidence to provide click-by-click instructions for the roadmap’s combined admin-center experience. There is enough to establish a useful preparation sequence around the documented user-data workflow.
1. Separate confirmed coverage from planned coverage
Build an inventory with distinct lists for user data and shared resources. Mark dependencies on the proposed SDM capability explicitly rather than treating them as already solved.
For a project that cannot wait for future delivery, the currently documented UDM boundary remains the safe planning baseline. Shared Teams and SharePoint content requires its own accounted-for workstream.
2. Establish authority and migration scope
Microsoft’s tenant-configuration guidance requires Global Administrator access for the configuration work in each tenant. Running migration through the documented PowerShell workflow can subsequently use a Global Administrator or Microsoft 365 Migration Administrator.
It also requires a source mail-enabled security group to scope the users whose content can move and support identity mapping. Record that scope deliberately: it is an authorization boundary, not merely a convenient mailing list.
3. Prepare destination users in the correct order
Microsoft’s prerequisites warn against pre-provisioning destination mailboxes or OneDrive sites, because doing so can cause migration failure. Identity Mapping must occur before migration and stamps the source Exchange GUID onto the target user. Microsoft also advises preventing OneDrive creation as soon as destination users are created.
The lesson is operational: account creation, mapping, and licensing need a controlled sequence. An otherwise helpful onboarding automation could create the very destination resources the migration expects not to exist.
4. Configure only the required workload services
The tenant-configuration documentation identifies applications and permissions for the migration service, OneDrive, Teams chats, and Teams meetings. It says administrators moving only a subset of workloads need perform the setup for those workloads.
For its current PowerShell setup, Microsoft lists Microsoft.Graph.Beta 2.33.0 or later and says Microsoft.Graph and Microsoft.Graph.Beta versions should match. These are prerequisites for that documented workflow, not announced requirements for the future admin-center interface.
5. Validate before committing the transition
Microsoft’s pre-migration checks cover duplicate batch membership, migration endpoints, organization relationships, application permissions, identity mappings, scope-group membership, and workload licenses. Teams requires licensing in both tenants; the meeting checks also require Exchange Online licensing in both.
When prevalidation fails, Microsoft says the migration is cancelled so administrators can correct the errors and submit a new batch. Fix the reported prerequisite rather than repeatedly submitting an unchanged configuration.
6. Define user-facing acceptance checks
As a practical recommendation, prepare checks for access to the destination mailbox, expected OneDrive content, the correct Teams identity, and the availability of required collaboration resources. Keep shared-data acceptance separate until the SDM behavior is documented.
A completed batch is an important technical milestone. Users being able to do their work is the outcome that matters.
APIs, licensing, and the remaining questions
The existing Graph API documentation describes creating, validating, retrieving, monitoring, updating, cancelling, and deleting migration jobs. It lists availability through both /v1.0 and /beta, while maintaining its user-data-only scope. Job names must be unique within a tenant, and jobs in progress cannot be deleted. These API operations do not establish which controls will appear in the planned admin-center interface.
For licensing, Microsoft’s UDM overview specifies a one-time, per-user migration add-on assigned to either the source or target user object. It lists eligibility across several Microsoft 365, Office 365, standalone-service, and education offerings. That does not establish final pricing or licensing terms for the roadmap’s SDM scope.
Before relying on the expanded offering, administrators still need answers about:
- SDM prerequisites and supported resource configurations.
- Permissions, membership, and post-migration access behavior.
- Shared-data licensing and migration limits.
- Recovery options when only part of a migration succeeds.
- The exact admin-center workflow and rollout availability.
These are planning questions, not claims that the feature will lack those capabilities.
The bottom line
Roadmap item 576273 is worth tracking because it explicitly brings shared Microsoft 365 resources into the proposed cross-tenant orchestration scope. The verified comparison with Microsoft’s existing documentation makes that more consequential than a routine interface update.
The sensible response is preparation, not premature commitment. Inventory both personal and shared data, control destination provisioning, validate identity mappings and permissions, and communicate workload-specific cutover behavior. Keep December 2026 as a planning estimate until delivery and detailed SDM documentation establish what is actually available.
Orchestration can simplify a complicated move. It does not eliminate the need to know what is moving, what stays behind, and which identity will open the door afterward.