Quick answer:<\/strong> The Microsoft 365 Migration Orchestrator is Microsoft’s native, PowerShell-driven tool for moving users’ Exchange mailboxes, OneDrive, Teams chats, and Teams meetings between tenants in coordinated batches. It moves content, not identities, needs a one-time per-user license, runs from the target tenant, and leaves Teams, channels, and SharePoint sites in the source tenant.<\/p>\n<\/div>\n Key Takeaways<\/p>\n The Migration Orchestrator is Microsoft’s self-service, PowerShell-driven tool for moving users’ personal data between Microsoft 365 tenants, built for mergers, acquisitions, divestitures, and internal reorganizations.<\/strong> Microsoft’s formal name for it is cross-tenant orchestrated user data migration.<\/p>\n It coordinates workloads in dependency order, validates your setup before anything moves, and keeps migration traffic inside the Microsoft boundary rather than routing it through a third-party service. It is built on the technology behind Microsoft’s generally available standalone mailbox and OneDrive migrations. What it adds is a single place to submit and monitor batches, mandatory validation, and, for the first time, a native cross-tenant path for Teams chats and meetings. Microsoft describes three architecture models:<\/p>\n Two limits apply to all of them. The Orchestrator is available in the public cloud only, and Microsoft states that cross-cloud migration is not supported, for example from Office 365 Worldwide to a Government Cloud. If you are moving to a government tenant<\/a>, it is not the tool for that leg of the project.<\/p>\n Microsoft launched the Orchestrator as a public preview in December 2025, and its current documentation no longer carries a preview notice, but we found no explicit general availability announcement, so confirm the status in your own tenant before building a project around it.<\/strong><\/p>\n The picture is mixed. Launch-era versions of Microsoft’s planning and FAQ pages said tenant-to-tenant migration was “currently available in preview” and that features might change before general availability. The versions of those pages, and of the overview, updated between May and July 2026, no longer say so, and they now cover operational topics such as cancellation, timing guidance, and troubleshooting. Against that, independent coverage as late as June 2026 still described the tool as being in preview.<\/p>\n The practical advice does not change either way: check Microsoft’s current documentation, ask your licensing partner, and run a small pilot batch early. If anything about the product shifts between now and your cutover date, you want to find out during the pilot, not during the migration.<\/p>\n It migrates four workloads for each user: Exchange mailbox content, OneDrive files, Teams chats, and Teams meetings.<\/strong> Microsoft recommends running all four in the same batch, and the Orchestrator sequences them to respect dependencies.<\/p>\n Only user-visible content migrates: email, contacts, calendar, tasks, and notes. Mailboxes on any type of hold are blocked from moving. After a successful migration the source mailbox is deleted and is no longer available or discoverable in the source tenant, and the source user is converted to a MailUser stamped with a routing address to the target, which allows coexistence and mail routing. The Orchestrator builds on the standalone mailbox tool<\/a>, so that tool’s limitations apply here too.<\/p>\n Cross-tenant OneDrive migration gives each target user a OneDrive and removes the source OneDrive, leaving a redirect link behind. Incremental and delta passes can’t be performed, so plan the cutover rather than expecting to catch up later. Microsoft also notes a limit of 4,000 SharePoint and OneDrive sites that can be queued to move at one time.<\/p>\n One-to-one and group chats are copied to the target. The Orchestrator creates new threads in the target tenant and edits the source threads. Voicemails travel too: received voicemails that arrived in email as attachments appear in the target mailbox, and the voicemail greeting migrates as well.<\/p>\n Meetings are updated when the organizer migrates. The meeting URL changes, the roster swaps source identities for target ones, and participants who haven’t migrated can join as guests, depending on tenant and meeting policy. Meetings depend on the mailbox move, which is why they can’t be selected without mailboxes and chats.<\/p>\n<\/ul>\n It does not migrate identities, Teams and channels, SharePoint sites, or groups, all of which stay in the source tenant or must be created separately in the target.<\/strong> Microsoft is explicit that the product moves content, not identities.<\/p>\n It requires a one-time, per-user Cross-Tenant User Data Migration license, assigned to either the source or the target user, and it is available through EA, CSP, web direct, small business, and education channels.<\/strong> Microsoft’s documentation doesn’t list a price, so confirm it with your licensing partner before you budget.<\/p>\n Not sure the Orchestrator fits your merger or divestiture?<\/p>\n Apps4Rent reviews your tenants, licensing, and user mix, then tells you honestly what the Orchestrator can cover and what needs another approach.<\/p>\n<\/div>\n<\/div>\n Get my free assessment \u2192<\/a><\/div>\n Before any batch runs you need tenant-level setup, correctly prepared target users, and completed identity mapping, and Microsoft’s validation will block anything that is missing.<\/strong> Most of the real work in an Orchestrator project happens here.<\/p>\n Every user whose content will move must be mapped before any migration begins. Without that mapping, Teams chat and meeting migration can’t add the correct users in every scenario. Identity mapping also stamps each source user’s Exchange identifier onto the target user, which is what prevents a mailbox from being created too early. Keep the mapping stable while batches are running: rerunning it with the Remove-CTIMData cmdlet mid-migration removes users whose mailbox migration has completed and damages their Teams experience, so add users by rerunning mapping without that cmdlet instead. Allow up to an hour for changes to the scope group to take effect.<\/p>\n You create a batch from the target tenant, fix validation errors until it passes, let mailboxes sync with no user impact, and then cut over at the CompleteAfterDate, after which the other workloads follow.<\/strong><\/p>\n Two details deserve extra attention. First, Microsoft’s pages disagree on batch size. The running-the-migration page, updated in June 2026, sets the maximum at 100 users, while the FAQ recommends keeping batches to 2,000 mailboxes and the launch announcement described batches of up to 2,000. Plan around the stricter figure of 100 and confirm in your own tenant, because it changes the math: 1,000 users means at least ten batches. Second, if a mailbox seems stuck more than a day after the CompleteAfterDate, Microsoft says a Data Consistency Score issue may be waiting for approval. A grade of Investigate can be approved so the migration completes with the items that could be transferred, while a grade of Poor should go to Microsoft Support rather than being approved.<\/p>\n Users keep access to their chats throughout and switch to their target identity afterward, but they will notice new and temporary chats, and several content types never move.<\/strong> Microsoft’s end-user documentation is unusually candid about this, and it is worth reading before you promise anyone a seamless move.<\/p>\n Chat behavior depends on the order in which people migrate. When both people in a one-to-one chat are migrating, nobody is removed from the original chat. Once the first person migrates, a temporary chat is created between that person’s target identity and the other person’s source identity, and when the second person migrates, a new chat is created between the two target identities. The temporary chat isn’t deleted. Group chats follow the chat’s owner, meaning whoever created it: when the owner migrates, a new chat is created in the target, and until then migrating participants are swapped in the original chat. Messages sent from the source after a thread has migrated don’t follow. Our Teams migration guide<\/a> covers the rest of the Teams picture.<\/p>\n Several chat items don’t migrate at all: self-chats, chats started by external users or by people who left or lost their Teams license, reactions, apps such as Polls, deleted messages, scheduled messages that were never sent, messages over 4 MB, code snippets, and hosted attachments that aren’t JPG, JPEG, or PNG files. Microsoft also scores each user’s chat migration: it fails the quality threshold if more than 20 percent of attempted messages or more than 10 percent of attempted threads fail to import.<\/p>\n For meetings whose last occurrence was within the previous 60 days, the URL updates, the meeting shows on calendars, and its chat stays attached. For older meetings, the URL isn’t updated and the messages migrate as a new group chat. Not migrated: recordings, transcripts, recaps, attendance reports, channel and shared channel meetings, live events, webinars, town halls, meetings over 250 attendees, canceled meetings, modified occurrences of recurring meetings, appointments with no Teams link, meetings on non-default calendars, resource mailbox meetings, and meetings marked Confidential or Highly Confidential. Every RSVP is reset, so attendees must respond again.<\/p>\n One instruction from Microsoft is easy to miss: don’t remove mail forwarding or delete source objects until the entire tenant migration is complete. Because migration happens in batches, updates to meetings that haven’t moved yet reach migrated users only through that forwarding.<\/p>\n<\/ul>\n Want your prerequisites checked before validation fails?<\/p>\n Most Orchestrator delays start with missed setup steps. Apps4Rent audits your tenant configuration, user preparation, and identity mapping before the first batch is submitted.<\/p>\n<\/div>\n<\/div>\n Get my free assessment \u2192<\/a><\/div>\n Use the Orchestrator for coordinated moves of users’ mailboxes, OneDrive, and Teams chats and meetings, and add other tools or a partner for everything it leaves behind.<\/strong> Microsoft’s own planning guidance frames the choice the same way: orchestrated migration for multi-workload moves, standalone tools for single workloads or granular control, and partner or third-party tools for complex migrations or when internal resources are limited.<\/p>\n\n
What Is the Microsoft 365 Migration Orchestrator?<\/h2>\n
\n
Is the Orchestrator Generally Available or Still in Preview?<\/h2>\n
What Does the Orchestrator Migrate?<\/h2>\n
![\"Diagram](\"https:\/\/www.o365cloudexperts.com\/blog\/wp-content\/uploads\/2026\/11\/orchestrator-moves-vs-stays.png\")
<\/p>\n\n
Exchange Mailboxes<\/h3>\n
OneDrive<\/h3>\n
Teams Chats<\/h3>\n
Teams Meetings<\/h3>\n
What Does the Orchestrator Leave Behind?<\/h2>\n
\n
What Does the Orchestrator Cost and Who Can Use It?<\/h2>\n
\n
What Do You Need Before You Start?<\/h2>\n
Tenant Setup<\/h3>\n
\n
Target User Preparation<\/h3>\n
\n
Identity Mapping<\/h3>\n
How Does an Orchestrator Migration Work, Step by Step?<\/h2>\n
![\"Diagram](\"https:\/\/www.o365cloudexperts.com\/blog\/wp-content\/uploads\/2026\/11\/orchestrator-batch-lifecycle.png\")
<\/p>\n\n
What Will Users Experience, and What Never Moves?<\/h2>\n
\n
Chats<\/h3>\n
Meetings<\/h3>\n
Orchestrator, Standalone Tools, Third-Party Tools, or Managed Migration: Which Fits?<\/h2>\n