Last updated: 21 July 2026
What actually carries across in an M365 tenant-to-tenant migration, what doesn't, and why clearing out mailboxes first — not after — is what actually shortens the project.
What actually moves
Mail items, folder structure, and calendar/contacts — the bulk of what a migration tool like BitTitan MigrationWiz, Quest On Demand, or ShareGate is built to move, with reasonable fidelity for most standard mailbox setups.
Retention policies and legal holds, on-prem AD-synced attributes, and some mail flow rules are tied to the source tenant's configuration, not the mailbox data itself — these need to be rebuilt in the destination tenant, not assumed to travel automatically.
The real cost driver
Migration tools move data at a rate bound by total mailbox size, and Microsoft's own throttling policies on both source and destination tenants slow large mailboxes down further. A 40GB mailbox doesn't take twice as long as a 20GB one — it takes considerably longer, since throttling compounds as volume grows.
A mailbox that's never been cleaned out often carries years of newsletters, automated notifications, and large attachments nobody has opened in years — routinely 30-50% of total size, none of which needs to survive a tenant move.
Migrating junk data across tenants and deleting it afterwards means paying for the transfer twice over — once to move it, once to clear it up again in the new tenant. Clearing it beforehand shrinks the migration window and, for tools priced by data volume or duration, the bill.
Mail items, folders, and calendar/contacts generally migrate across intact when using a proper migration tool (e.g. BitTitan MigrationWiz, Quest On Demand, ShareGate). What doesn't automatically carry over: on-prem AD-synced attributes, some retention/hold configurations (these need to be recreated in the destination tenant), and anything tied to the source tenant's identity, like certain mail flow rules or Teams-linked data. Always confirm your migration tool's exact scope against your specific mailbox setup before assuming full parity.
Yes, directly. Every tenant-to-tenant migration tool moves data at a rate bound by mailbox size — most are priced per seat but timed and throttled by total GB moved, and Microsoft's own throttling policies slow large mailboxes down further. A mailbox that's been in use for years without ever being cleared often has 30-50% of its size in newsletters, old attachments, and automated notifications nobody reads — none of which needs to survive the move. Clearing that first shrinks both the migration window and, for tools billed by data volume or migration duration, the invoice.
Before, in almost every case. Migrating junk mail across tenants and then deleting it afterwards means paying for the transfer of data you were always going to throw away, and it doubles the work — once to move it, once to clean it up in the new tenant. The only exception is when a retention or legal hold requires certain mail to survive the move regardless of size; that mail should stay untouched either way.
It shouldn't, provided the cleanup tool respects retention policies and legal holds already in place, the same requirement that applies to any bulk mailbox action. MailBroom's Smart Sweep and Storage Cleanup work within existing Exchange Online retention and hold settings rather than around them, so held items are preserved regardless of what an employee or IT admin clears elsewhere in the mailbox.
MailBroom for Business is licensed per organisation (per Microsoft 365 tenant) via Microsoft SSO — IT signs in once with an admin account for that tenant, and every employee on the domain gets access automatically. For an MSP managing several client tenants ahead of a migration, that means setting it up separately per client tenant being migrated, not a single MSP-wide login across all of them.
Smart Sweep and Storage Cleanup let every employee clear their own mailbox ahead of a tenant migration — no per-mailbox IT time, no waiting on a migration vendor's clock.