When native migration runs out of road, you buy a tool
Native cross-tenant tooling is good at the workloads Microsoft chose to cover. The trouble starts at the edges — the chat history, the coexistence window, the reporting across five thousand users — and that edge is exactly where a third-party migration tool earns its price.
New to cloud? CAMPUX is a free, build-first course. Start here →
Every tenant merger reaches the same fork. You start with the native tooling — it is free, it is supported, it does the obvious workloads well — and then someone asks for the Teams chats, or you realize the two companies need shared calendars for the six weeks before cutover, and native has no answer. This note, part of the Azure tenant-to-tenant migration guide, is about that fork: when to stay native, when to buy, and how to judge the tools without falling for a demo. If you have not yet seen what Microsoft ships in the box, read the native tooling landscape first, because you buy a tool to fill the gaps native leaves, and you cannot see the gaps until you know the baseline.
Why teams reach for a tool at all
Nobody buys migration software for fun; it is a line item you justify to a finance person. Four gaps drive most purchases. The first is workload coverage — private Teams chat history has historically not moved between tenants with native tooling, and that alone sends many projects shopping. The second is coexistence: during a phased cutover, users in the old tenant and the new one need to see each other's calendars, address books, and sometimes mailboxes, and native migration does not orchestrate that shared middle state. The third is device and endpoint state — Intune enrollment, compliance, and configuration do not follow a user across a tenant boundary on their own. The fourth is scale and reporting: scheduling waves of thousands of users, running repeat passes, and producing the per-user status report your project manager lives by is orchestration native tooling was never built to do.
You are not buying features. You are buying coverage, orchestration, and a report you can defend.
An ecosystem of vendors sells into exactly these gaps. Names you will hear in any procurement conversation include Quest On Demand Migration, BitTitan MigrationWiz, AvePoint, ShareGate, and CoreView, alongside Microsoft's own Migration Manager for file shares. I am naming that they exist, not ranking them — the right one depends entirely on your workloads, your identity complexity, and your timeline, and a claim that any single product is best is a claim you should distrust on sight.
The criteria that actually decide it
Ignore the feature matrix on the vendor's homepage and score every candidate on the same short list. Workload coverage: name every workload you must move — mail, OneDrive, SharePoint, Teams chats and channels, Planner, Power Platform, devices — and check coverage per workload, not in aggregate, because "supports Teams" can mean channels but not private chats. Coexistence: does it provide directory sync and free/busy sharing between the tenants during the transition, or only a one-shot copy. Delta passes: can it run repeatable incremental passes so the final cutover moves only what changed since the bulk run, instead of a stale snapshot. Reporting and rollback: per-item logs, per-user status, and a sane story for what happens to a batch that half-fails. Security model: which permissions it demands in each tenant, and whether content routes through the vendor's cloud or moves directly. Support and cost: licensing shape, per-user versus per-workload pricing, and whether real humans answer at 2 a.m. on cutover weekend.
A migration tool is one of the most privileged things you will ever run. Most want an app registration or admin consent in both tenants, frequently with broad Microsoft Graph and Exchange permissions so they can read and write mail, files, and directory objects for every user. That is a legitimate need — you cannot move a mailbox you cannot read — but it is also a standing key to two companies' data. Scope it to what the migration requires, time-box the consent to the project window, log what the tool does with it, and revoke the access the day the migration signs off. Ask each vendor plainly whether your content transits their servers or moves tenant to tenant directly; both models exist, and the answer belongs in your security review, not a footnote.
Native versus bought, said honestly
The default that keeps projects out of trouble is simple: use native where it exists, and buy a tool for the gaps and the orchestration. If your move is a clean set of mailboxes, OneDrives, and SharePoint sites with no coexistence window and no chat-history requirement, native cross-tenant tooling plus a little PowerShell is often enough, and you keep the money. The moment the scope includes workloads native does not cover, a real coexistence period, or waves of users that need scheduling and a defensible report, a tool stops being a luxury and becomes cheaper than the alternative — which is a team of engineers hand-stitching the gap with scripts, missing the delta passes, and explaining to leadership why three hundred people lost their chats. Buy for the gap, not for the whole job, and you rarely overspend.
How to run the evaluation
Do not evaluate on a slide deck. Take a small, representative slice of real users — one with a fat mailbox, one with heavy Teams usage, one with a device you care about — and run a paid proof of value through two shortlisted tools against a throwaway destination. Measure what the demo never shows you: how a partial failure reports, whether a second delta pass is genuinely incremental or silently recopies everything, how permissions are preserved on migrated SharePoint content, and what the support experience feels like when you file a real ticket. The tool that survives contact with your actual data, not the one with the smoothest sales engineer, is the one to buy.
The takeaway
Third-party migration tools are not a native replacement and not an admission of failure; they are the orchestration layer you rent when the job outgrows what Microsoft ships. Know your baseline, list your gaps, and score every candidate on coverage, coexistence, delta passes, reporting, the security model, and cost — the same list, every vendor. Stay native where native is enough, buy deliberately for the gap, read the permissions like they are a loaded weapon, and prove it on real data before you commit. That is how you spend the migration budget once and defend it later.
Questions people also ask
Does Microsoft have a native tenant-to-tenant migration tool?
Partly. Microsoft ships native cross-tenant tooling for specific workloads — mailboxes, OneDrive, and SharePoint sites — plus Migration Manager for file shares and a newer, license-gated cross-tenant user data migration path. There is no single button that moves an entire tenant. The native tools are strong inside their lane and simply do not cover some workloads, which is where a third-party tool comes in.
Can you migrate Teams chat history to another tenant?
Native tooling has historically not moved private Teams chat history between tenants, and the newer cross-tenant paths are limited and license-gated. This is one of the most common reasons teams buy a third-party tool. Verify current coverage before you promise anyone their chats, because the honest answer changes as Microsoft ships, and some tools rebuild chats better than others.
Do you need a third-party tool for tenant-to-tenant migration?
Not always. If your move fits the native workloads and you have no coexistence window, native tooling plus scripting is often enough and cheaper. You reach for a tool when you need workloads native does not cover, coexistence between the tenants during the cutover, or scheduling, delta passes, and reporting across thousands of users that native tooling does not orchestrate.
What permissions do third-party migration tools require?
Most need a privileged app registration or admin consent in both the source and destination tenants, often with broad Graph and Exchange permissions so they can read and write mail, files, and directory data. Treat that as a real security decision: scope it, time-box it, log it, and remove the consent when the migration is done. The tool's access is only as safe as your review of it.
What is a delta or incremental migration pass?
A delta pass copies only what changed since the last run. You do a bulk migration ahead of the cutover, then run incremental passes to catch new mail and edited files, so users move to fresh data instead of a days-old snapshot. Native tools are often one-and-done, while good third-party tools make repeatable delta passes routine — a real reason to buy one.