Every Office 365 migration kickoff eventually arrives at the same whiteboard moment: native hybrid mailbox moves or a third-party tool, which in practice means BitTitan MigrationWiz. We have run both at scale — 15,000-plus mailboxes across government and enterprise estates over the past few years — and we have opinions. This is our honest MigrationWiz review alongside the native Office 365 migration tools, organized by the only thing that matters: the scenario in front of you.
The short version: neither one is "better." They are different machines built for different jobs, and the teams that get burned are the ones who picked a tool before they understood their source environment. We have seen a 4,000-seat healthcare group insist on MigrationWiz for a clean Exchange 2013 hybrid (wrong call, cost them fidelity on move-request reporting they already had for free), and we have seen a state agency try to hybrid-migrate out of Exchange 2007 SP3 without wanting to touch the on-prem estate first (also wrong; that is exactly what MigrationWiz cutover exists for).
So instead of a verdict, here is the decision framework we actually use, with the numbers we have measured.
Where native hybrid moves win
If your source is Exchange 2010 SP3 or later, your directory is synchronized with Azure AD Connect, and you can stand up the Hybrid Configuration Wizard without breaking out in hives, native mailbox moves are the default answer and you should need a reason to deviate.
The killer feature is that a hybrid move is not a copy — it is a Mailbox Replication Service (MRS) move request. That buys you things no third-party tool can replicate:
- The user's Outlook profile survives. After the move completes, autodiscover repoints the profile to Exchange Online and the OST stays intact. No profile rebuild, no full OST re-download across your WAN, no helpdesk storm. On a 15,000-mailbox program, profile rebuilds alone would have added an estimated 2,500 helpdesk tickets. That number came from our pilot cohort's ticket rate, extrapolated — and it is why we fought for hybrid on that engagement.
- Incremental sync and a scheduled cutover. You seed mailboxes days or weeks ahead with
New-MoveRequest -SuspendWhenReadyToComplete, then complete batches on your schedule. Cutover night is a delta sync, not a bulk copy. - True fidelity. Dumpster (recoverable items), in-place holds, mailbox permissions on the moved mailbox — MRS carries them. Tools that talk EWS to both sides approximate this; MRS just moves it.
- It is free. No per-mailbox license. On 15,000 seats that is real money — more on that below.
The operational tooling matters too. Get-MoveRequestStatistics -IncludeReport will tell you exactly why mailbox 11,304 is stalled (usually a corrupt item count or a resource-throttling stall on the source database). You are debugging inside a supported Microsoft pipeline, and Premier support will engage on it.
Where MigrationWiz wins
MigrationWiz earns its license fee the moment your source stops being healthy, modern Exchange.
Cutover and staged scenarios without hybrid plumbing. A 600-seat client on Exchange 2007 with a domain controller estate nobody trusted did not want six weeks of remediation to earn the right to run the HCW. MigrationWiz talked to the source over Outlook Anywhere, we ran a two-pass migration (full pass during the week, delta pass at cutover), and the on-prem estate was decommissioned rather than repaired. That is the correct shape for that problem.
Non-Exchange sources. This is not a contest. For Lotus Notes/Domino and Google Apps — pardon, G Suite, we are still adjusting — native tooling ranges from limited (IMAP migration moves mail only, no calendar, no contacts) to nonexistent. We wrote up our Notes migration in April; MigrationWiz plus a Domino coexistence strategy was the entire engine of that project. For G Suite, MigrationWiz maps Gmail labels to folders with configurable rules, and brings calendar and contacts along. IMAP brings you mail with your labels exploded into duplicate copies per label. Choose accordingly.
Tenant-to-tenant. Divestitures and acquisitions have no native path. Microsoft has nothing that moves a mailbox between two Office 365 tenants. MigrationWiz does this routinely.
Speed to first mailbox. A MigrationWiz project can be moving pilot mailboxes the same afternoon. A hybrid deployment is realistically one to three weeks of prerequisite work — certificates, ADFS or password sync decisions, HCW, mail flow validation — before the first move request.
Throughput: the numbers nobody puts on the datasheet
Both tools are throttled by the same ceiling: Exchange Online ingestion throttling and your source's ability to serve data. Vendor throughput claims assume neither exists.
What we measure in the field:
| Scenario | Sustained rate we plan for |
|---|---|
| Hybrid MRS moves, healthy Exchange 2013 source, good WAN | 8–15 GB/hour per migration endpoint batch |
| MigrationWiz from Exchange 2010, Outlook Anywhere source | 0.5–1.5 GB/hour per mailbox, 30–50 concurrent |
| MigrationWiz from G Suite | 0.3–1 GB/hour per mailbox (Google API quotas dominate) |
| IMAP migration | Do not plan; suffer |
The practical implication: on a 15,000-mailbox program with a 1.8 GB average mailbox, we scheduled 27 TB of movement. With MRS we sustained roughly 2 TB per night across staggered batches. Third-party EWS-based copying at the same concurrency would have been slower and would have hammered the source CAS array harder — MRS is polite to the source in ways EWS bulk reads are not.
One MigrationWiz note that surprises people: throughput scales with concurrency, and concurrency is limited by the source, not by BitTitan. Their infrastructure will happily run 500 concurrent migrations. Your Exchange 2010 CAS array will not happily serve them. We watch RPC latency on the source and back off before users do it for us.
The licensing math
MigrationWiz mailbox licenses run roughly 12 dollars per mailbox at list for the standard mailbox product (the User Migration Bundle, which adds documents and personal archives, is more). Volume pricing improves that, but the shape holds:
- 500 mailboxes: about 6,000 dollars. Compare that to a week of consulting effort to build hybrid, and MigrationWiz is often cheaper even when hybrid is technically possible.
- 15,000 mailboxes: six figures. Compare that to the same week of hybrid effort — which does not scale with mailbox count — and native moves win by an absurd margin.
The crossover point in our engagements lands somewhere between 800 and 1,500 seats, assuming a hybrid-capable source. Below it, buy the tool and keep the project short. Above it, the per-mailbox fee buys you nothing MRS does not already do, so invest in the hybrid plumbing — which you likely want anyway for coexistence and offboarding.
There is one asterisk: if the org will run hybrid long-term for coexistence (a multi-year, multi-agency government migration, say), hybrid is not an option, it is a requirement, and the tool question evaporates regardless of seat count.
Rollback stories, because you will ask
Native hybrid: rollback is an offboarding move request. The same MRS machinery moves the mailbox back on-prem, profile intact. We have exercised this exactly twice in 15,000-plus mailboxes — once for a line-of-business application that turned out to speak WebDAV to the mailbox (yes, in this decade), once for a legal-hold complication that needed on-prem residency while lawyers argued. Both moves back were boring, which is the highest compliment in this business.
MigrationWiz: there is no "back," because there was no move — the source mailbox is still sitting there untouched. Your rollback is a DNS and autodiscover change repointing users at the source, plus accepting the loss of anything delivered to the cloud mailbox after cutover (or a reverse-direction MigrationWiz pass, which we have done once; it works, it is not fun). This is genuinely one of the underrated properties of copy-based migration: the source is your rollback until you delete it. We keep decommission gates at 30 days post-cutover for exactly this reason.
The failure mode to fear with copy-based tools is not rollback, it is silent partiality — a mailbox that reports complete with 200 skipped items. MigrationWiz surfaces per-item errors if you look; the discipline is making a human look. Our runbook requires the error report exported and triaged for every batch before we call it done. Corrupt calendar items from 2009 are usually shruggable. Skipped folders are not.
The decision table we hand to clients
- Exchange 2010+ source, over about 1,000 seats, directory sync feasible: native hybrid moves.
- Exchange 2003/2007, or an estate you refuse to remediate: MigrationWiz cutover or staged.
- Under about 800 seats and you want it done this month: MigrationWiz, even from healthy Exchange.
- Notes, G Suite, IMAP-land: MigrationWiz, no debate worth having.
- Tenant-to-tenant: MigrationWiz or a competitor; native offers nothing.
- Long-term coexistence requirement: hybrid, full stop; seat count irrelevant.
The tools are not rivals so much as adjacent specialists. The expensive mistake is loyalty to either one.
If you're facing this
If you are staring at a mailbox migration and the tool question is blocking the schedule, we have run this decision — and both tools — at everything from 500 seats to 15,000-plus. Get in touch and bring your source environment details; the right answer usually falls out in the first conversation.