A manufacturing company acquires a competitor and plans to bring its 4,000 employees into the parent Microsoft 365 tenant. The IT team reads about Microsoft’s cross-tenant migration orchestrator and concludes that the migration will be mostly automated. The pilot goes smoothly: mailboxes, OneDrive files, and Teams chats move for a test group. Then the real scope emerges. The acquired company has 900 SharePoint sites, 600 Teams with channel conversations and files, hundreds of Power Apps and flows, Intune-managed laptops, sensitivity labels, and mailboxes under litigation hold. None of those move with the orchestrator. The project timeline doubles.
This is a common pattern in tenant-to-tenant migrations. Microsoft’s native tools have improved, and they handle personal user data well. But the complex parts of a migration usually sit outside those tools. Office 365 migration consulting delivers the most value in that remainder: shared content, collaboration spaces, automation, device management, security and compliance, and the identity and cutover planning that ties everything together.
What Microsoft’s Orchestrator Covers
Microsoft’s migration orchestrator overview describes tenant-to-tenant migration for mergers, acquisitions, divestitures, and reorganizations. It supports four workloads for individual users:
- Exchange mailboxes, limited to user-visible content such as email, contacts, calendar, tasks, and notes
- OneDrive, with the source leaving a redirect link after migration
- Teams chats
- Teams meetings, which require mailboxes and chats to be migrated in the same batch
Microsoft recommends migrating all workloads for a user in the same batch so the orchestrator can handle dependencies. Cross-tenant migration requires a one-time per-user license.
What It Does Not Cover
The same documentation is clear about the limits. The orchestrator moves content, not identities; customers must create and configure users in the target tenant. It does not migrate shared data such as Teams and channels or SharePoint sites, which remain in the source tenant. Mailboxes on any type of hold are not migrated, and moves for those mailboxes are blocked.
Beyond those stated limits, several other areas require their own plans in most migrations:
- SharePoint sites and hubs, including permissions, metadata, and customizations
- Teams and channels, including channel conversations, files, tabs, and apps
- Power Platform assets, such as Power Apps, Power Automate flows, Copilot Studio agents, and Dataverse environments
- Intune and device management, including enrollment, compliance policies, and configuration profiles
- Security and compliance settings, including sensitivity labels, data loss prevention policies, retention policies, and eDiscovery holds
- Identity configuration, including groups, conditional access, and application registrations
- Line-of-business integrations that depend on tenant-specific settings
Where an Office 365 Migration Assistant Fits
Native tools and third-party migration assistants play an important role. An Office 365 migration assistant, whether Microsoft’s orchestrator or a specialist tool, automates bulk data movement, tracks progress, and reduces manual errors. For personal data, these tools can move large volumes reliably.
What an Office 365 migration assistant cannot do is decide how the target tenant should be organized, which content should move, how permissions should be mapped, or how users will experience cutover. Those decisions shape whether the migration succeeds.
SharePoint: The Largest Remainder
SharePoint often holds the most complex content in a tenant. Migrating it involves:
- Inventory: Sites, hubs, libraries, lists, pages, and customizations
- Rationalization: Deciding which sites to move, merge, archive, or retire
- Information Architecture: Mapping source sites into the target structure
- Permission Mapping: Translating users and groups to target identities
- Metadata and Versions: Preserving content types, columns, and version history where needed
- Customizations: Rebuilding SPFx solutions, workflows, and integrations
- Link Fixing: Updating links in documents, pages, and navigation
With Copilot grounding answers in SharePoint content, permission mapping also carries new weight. Microsoft notes that Copilot only surfaces data that users have at least view permissions to access, so broad or incorrect permissions after migration can expose content in AI answers.
Teams and Channels
Teams migrations require care because channels combine conversations, files, and apps:
- Channel conversations need a migration method that preserves history
- Channel files live in SharePoint and follow SharePoint migration rules
- Private and shared channels have their own sites and membership
- Tabs, apps, and connectors must be reconfigured
- Team ownership and membership must be mapped to target identities
Users often care most about channel history and files. A plan that moves chats but leaves channels behind can frustrate users quickly.
Power Platform Assets
Apps, flows, and agents are frequently overlooked in migration planning. They depend on connections, environment settings, Dataverse data, and user identities that change between tenants. Migration typically involves:
- Inventory of apps, flows, agents, connectors, and environments
- Solution packaging where assets are not already in solutions
- Connection and connection reference updates for the target tenant
- Dataverse data migration for environments that hold business data
- Testing each asset in the target environment
Unmanaged personal flows are often the hardest, because nobody tracks them until they break.
Devices and Intune
Moving users to a new tenant usually means moving their devices. Intune-managed devices must be re-enrolled in the target tenant, with compliance policies, configuration profiles, and applications recreated. Autopilot registrations, BitLocker keys, and conditional access policies all need attention. Poor device planning can leave users unable to sign in on cutover day.
Security and Compliance Content
Security and compliance settings require specialist planning:
- Sensitivity labels must exist in the target tenant with compatible configurations, or labeled content may become inaccessible.
- Encrypted content may need to be re-protected or decrypted and re-labeled.
- Retention policies and holds must be recreated, and held mailboxes planned separately.
- Data loss prevention policies must be rebuilt.
- Audit and eDiscovery requirements must be met for both tenants during and after migration.
Legal and compliance teams should be involved early, especially in regulated industries.
Identity and Cutover Planning
Because the orchestrator moves content rather than identities, identity work is a major workstream:
- User creation and mapping between source and target.
- Group mapping for Teams, SharePoint, and security groups.
- Mail routing and coexistence during phased migrations.
- Domain moves and DNS changes.
- Single sign-on and application access for line-of-business apps.
- Communication and support for users on cutover day.
Phased migrations need coexistence planning so users in both tenants can collaborate.
Divestitures and Tenant Splits
Not every migration consolidates tenants. Divestitures often require the opposite: carving a business unit out of a shared tenant into a new one, sometimes under a transition services agreement with a fixed end date. Splits carry their own challenges. The team must identify exactly which users, sites, Teams, mailboxes, and apps belong to the divested unit, and shared content used by both sides needs a decision on who keeps the original and who receives a copy.
Legal constraints are tighter in divestitures. The buyer should not gain access to content that belongs to the seller, and the seller may need to retain records for regulatory or litigation purposes after the split. That calls for careful scoping, access reviews before migration, and documented approvals for any shared content that crosses the boundary.
Timelines add pressure. Transition services agreements often limit how long the seller will support the divested unit’s systems. Planning must work backward from that date, with buffer for testing and remediation, because extending the agreement is usually expensive.
Measuring Migration Success
Clear measures help teams know whether a migration is on track:
- Workload completion: share of mailboxes, OneDrive accounts, sites, Teams, and apps migrated and validated.
- Error rates: failed items per batch and time to resolve them.
- User impact: support tickets per migrated user in the first two weeks.
- Coexistence health: mail flow, calendar sharing, and cross-tenant collaboration working as planned.
- Compliance continuity: holds, retention, and labels in place before and after each move.
- Source decommissioning: licenses and services removed from the source tenant on schedule.
Tracking these measures from the pilot onward gives leadership an honest view of progress and helps the team adjust batch sizes, tools, and support staffing as the migration scales.
What Office 365 Migration Partners Should Provide
Office 365 migration partners focused on complex migrations should deliver:
- Discovery and assessment across all workloads, not just mailboxes and OneDrive.
- Target tenant design for identity, SharePoint, Teams, Power Platform, devices, and compliance.
- Tool selection combining Microsoft’s orchestrator with specialist tools where needed.
- Workload-specific migration plans for SharePoint, Teams, Power Platform, Intune, and compliance content.
- Pilot migrations covering representative users and content.
- Cutover planning with communication, support, and rollback options.
- Post-migration cleanup of the source tenant and validation in the target.
These office 365 migration services cover the parts native tools leave behind.
Choosing Office 365 Migration Consulting
When selecting an office 365 migration consultant or team of office 365 migration experts, organizations can ask:
- How will the partner migrate SharePoint sites, Teams channels, and Power Platform assets?
- How will labeled, encrypted, and held content be handled?
- What is the plan for Intune-managed devices?
- Which tools will be used for each workload, and why?
- How will identity mapping and coexistence work?
- What does a pilot include, and how will success be measured?
A partner that focuses only on mailbox and OneDrive migration may underestimate the real scope.
A Representative Plan
Return to the manufacturing company. With a consulting partner, it redesigns the project. Mailboxes, OneDrive, and Teams chats move through Microsoft’s orchestrator in batches. SharePoint sites are rationalized from 900 to about 500, with the rest archived, and migrated with a specialist tool. Teams channels move with history preserved. Power Platform assets are inventoried, packaged, and tested. Devices are re-enrolled through Autopilot. Sensitivity labels and retention policies are recreated before content moves, and held mailboxes follow a separate legal-approved process.
The migration completes in phases over several months, with users able to collaborate across tenants during coexistence.
Office 365 migration consulting now earns its value in the remainder that native tools do not cover: SharePoint, Teams channels, Power Platform, devices, and compliance content. Microsoft’s orchestrator simplifies personal data moves, which makes planning the rest even more important. Professional Office 365 migration services cover assessment, tenant design, and workload-specific migrations. Before the next tenant migration begins, it is worth asking how much of the tenant the orchestrator will move.