Table of Contents
Why is Microsoft Getting into the Tenant-to-Tenant Migration Market
I’ve listened to many Microsoft presentations about tenant-to-tenant (T2T) migration over the years. Each time, Microsoft’s interest faded when they realized the complexities involved in moving information from one Microsoft 365 tenant to another. It’s not just the engineering work to build migration functionality. After all, Microsoft has probably moved more mailboxes into the cloud and around the cloud than any other company. The problems seemed to be with support. Rather, the lack of desire within Microsoft to be responsible for migration projects that can become very sticky and troublesome.
It seemed like Microsoft was happy to leave the difficulties involved in T2T to ISVs, many of whom like Quest, BitTitan, ShareGate, and AvePoint, have worked on T2T tools and techniques for years and have lots of experience in this area. Indeed, Microsoft’s T2T migration architecture model (from 2021) highlights the use of third-party tools to move data. But now we have the Migration Orchestrator (in preview), announced in MC1198079 (16 December 2025).
The Migration Orchestrator can move mailboxes, OneDrive for Business accounts, and Teams chats. Mailbox migration has existed for a while and can handle primary and archive mailboxes.
Licensing
ISVs charge for their T2T solutions, and so does Microsoft. User accounts involved in a migration need Microsoft 365 E3 or E5 licenses and a Cross-Tenant User Data Migration license is required for each account to move mailbox and/or OneDrive information.
PowerShell Driven Migration
It might surprise some, but the Migration Orchestrator is controlled by a set of Graph APIs accessed as Microsoft Graph PowerShell SDK cmdlets (in version 2.33) like New-MgBetaCrossTenantMigrationJob (submits a new migration job for processing).
The implementation doesn’t surprise me at all. T2T migration processes are usually carefully planned and executed with lots of up-front work like the cross-tenant identity mapping process that must be done before any migration jobs can be run. It might be nice to have a UX but given that T2T migration is not core Microsoft 365 functionality, it makes sense to run everything through PowerShell.
Downsides
Like any migration, some restrictions exist. Microsoft won’t move mailboxes if they’re covered by any sort of hold, so some up-front work might be needed to determine whether any holds exist for mailboxes that should move and if it’s possible to release those holds without losing data. Releasing mailboxes from eDiscovery holds is usually the hardest problem because the fact that mailboxes are held for eDiscovery is a good indicator that some ongoing investigations need the information.
Another issue is that only IPM (data visible to email clients) is moved. Anything stored in non-IPM folders like Teams compliance records is left behind. This is in line with the general stance that compliance data belongs to the tenant in which the records are generated.
Migration orchestrator doesn’t include a method to deal with messages and documents protected by sensitivity labels. The way sensitivity labels work, the labels from one tenant must be removed before items leave the source tenant. Microsoft deals with the issue in a rather old blog (2019). However, ISVs have worked out ways to migrate protected content, and this could be an important point to consider depending on how your tenant uses sensitivity labels.
Microsoft’s Big Advantage
The biggest thing going for the Migration Orchestrator is that the data it processes remains within Microsoft datacenters. There’s no need to move data out of a tenant to an intermediate location before moving the data back to the target tenant. Given the amount of information accumulated in mailboxes, OneDrive accounts, and Teams chat, the speed of migration is important, and you can’t go any faster than when information stays within Microsoft.
ISVs will hate that Microsoft has the speed advantage, but they’ll argue that a phased and controlled migration can accomplish the same goal, albeit slower. ISVs will also point out their ability to deal with different use cases, like protected documents. And ISVs will love that Microsoft has legitimized T2T as a valid approach for tenant splits, joins, and mergers, so everyone will be happy.
Insight like this doesn’t come easily. You’ve got to know the technology and understand how to look behind the scenes. Benefit from the knowledge and experience of the Office 365 for IT Pros team by subscribing to the best eBook covering Office 365 and the wider Microsoft 365 ecosystem.
One Reply to “Microsoft Tenant-to-Tenant Migration Orchestrator”