Migration tooling
The tool is chosen for the migration.
There are two ways a Microsoft 365 estate can be moved. They differ in who does the moving, and that changes what is possible. Neither one moves most of what a tenant actually contains. That is the part worth knowing before you compare proposals.
Two ways to move it
Every proposal you receive will be one of these, whether or not it says so.
The target tenant pulls the content across
Microsoft operates the movement between two Microsoft 365 tenants. Before any mailbox moves, each user object in the target is stamped with the identifiers that tie it to its source. Microsoft documents that every object has to reach a completed state before a mailbox will move at all. The mapping is a prerequisite, not a reconciliation afterwards.
What it addresses is narrow and well defined: mailboxes, OneDrive, and Teams chats and meetings.
A platform you run does the moving
A migration service reads from the source and writes to the target, on a schedule someone sets. Content is normally staged ahead of the cutover, then a final pass picks up what changed while people carried on working.
A final pass is not synchronization. The vendor's own documentation is explicit that it does not propagate updates, deletions or items that moved between folders, and that anything moved after it ran arrives as a duplicate. That single behavior decides how a cutover window is drawn.
The difference is not quality. It is who is operating the move. That decides what can be changed on the way, and what has to arrive exactly as it left.
Published by Microsoft: Cross-Tenant Identity Mapping · Migration orchestrator overview
What neither method moves
This is the section people forward to someone else. A tenant is not four workloads — and a tool license is not a migration plan.
Microsoft states it plainly about its own migration: it “moves content, not identities”, and “customers are responsible for correctly creating and configuring users.” Creating and configuring the users is the identity project, and it sits outside the tool entirely.
On shared collaboration data, Microsoft is equally direct — its migration “doesn't migrate shared data… This data remains in the source tenant.” Teams themselves, their channels, and SharePoint sites are outside its scope. They are rebuilt in the target and then populated. That is a different piece of work, with a different window.
Beyond that, neither method carries any of the following, and all of them are part of the estate somebody has to move:
- Conditional Access policies and the security posture built out of them
- Devices, and their enrollment and compliance state
- Enterprise applications and app registrations
- Automations, scheduled scripts and anything holding its own credentials
- Every third-party system that authenticates against the tenant, which is usually the list nobody has
None of this is a criticism of either method. Both do what their documentation says they do. The engineering lives in the gap between what the tool moves and what the organization runs on. That gap is the part a proposal built around a product name tends to leave unpriced.
Published by Microsoft: Migration orchestrator overview
How the choice is actually made
Find the row that describes your estate. The method follows from the situation, which is the only order in which the question can honestly be answered.
| Your situation | What it points to | Why |
|---|---|---|
| One Microsoft 365 tenant into another, and the workloads map across as they are | Microsoft's own services, evaluated first | Identity mapping is written onto the target objects before anything moves, so the accounts arrive already resolved rather than matched afterwards by a third system. |
| Several sources at once, or a source that is not Microsoft 365 | A third-party platform | Microsoft's cross-tenant services move between Microsoft 365 tenants. A hosted Exchange estate, an IMAP platform or a Google tenant is outside what they address — see email and complex sources. |
| Content has to be restructured on the way — sites merged, permissions reworked, structure changed | A third-party platform | A platform you drive can map source to target deliberately. A service that copies content across copies the structure with it. |
| Teams themselves, channels, or SharePoint sites have to arrive in the target | Neither, on its own | The row people are most often surprised by, and the section above is where Microsoft says so. It becomes a rebuild in the target with content moved into it — planned as its own work, with its own window. |
| Mailboxes are on legal hold or litigation hold | Plan around it before the wave is drawn | Microsoft documents that a mailbox on any kind of hold is blocked from migration. Discovered mid-wave it stops that wave; discovered in assessment it is a sequencing decision. |
| Teams private chat history has to come across | Check the documented window before promising it | Both methods bound this, and the bounds are narrow enough that the answer belongs in the plan rather than in a reassurance. |
Cost belongs in this decision, and it is never the license on its own. It is the license plus the engineering the method leaves you holding. That is why the cheaper tool is regularly the more expensive migration.
The names, for when you meet them in a proposal
Deliberately last. If a firm leads with one of these, it has told you what it owns rather than what your estate needs.
- Cross-Tenant Synchronization
- Keeps user accounts present and current in a second tenant while both are live. It is what makes people findable to each other during a consolidation, not a migration in itself.
- Cross-Tenant Identity Mapping
- The prerequisite step above. The target objects are stamped with their source identifiers, and the mapping has to complete before mailboxes will move.
- Microsoft 365 Migration Orchestrator
- Microsoft's own cross-tenant movement of mailboxes, OneDrive, and Teams chats and meetings.
- MigrationWiz
- BitTitan's migration platform — the third-party route, and the one that handles source diversity and restructuring that the native services do not address.
One name that is not a tool. Microsoft FastTrack is a delivery service rather than a product, and its scope is not the same as the product's — so what FastTrack excludes should never be read as something the tooling cannot do.
It is worth knowing what it says about itself, because it describes the same gap this page opened with: it “does not include architecture planning, solution design, or post-migration orchestration activities”, and it recommends engaging a partner for them.
Published by Microsoft: Migration orchestrator overview · FastTrack cross-tenant migration
Which one your estate needs is a finding, not a preference
Source platforms, holds, restructuring and the systems authenticating against the tenant all decide the method — and all of them are things discovery establishes rather than things a proposal can assume.