This guide covers one specific job: on-premises Exchange to Microsoft 365 mailbox migration, including primary mailboxes, on-premises archives, and the shared-mailbox and permission dependencies that come with them. “Large-scale” here means two things at once: mailboxes that exceed Microsoft’s own 100 GB planning threshold, and estates big enough to require multiple batches rather than a single weekend swat.
The outcome to plan for is minimal business disruption, not zero downtime. Platform limits and prerequisites set the boundaries; the scheduling, throttling, and batch-sizing heuristics below are practice-based estimates rather than guarantees.
Quick Take
The golden rule for a large Exchange move: classify the estate before comparing methods, then make three readiness items non-negotiable: backup, archive provisioning, and license assignment. Hybrid coexistence is the standard low-disruption pattern for enterprise scale, but it still interrupts users at finalization. Run one pilot batch with autocomplete disabled, verify it, and keep the source recoverable until every post-migration check passes.
Decision criteria: classify the estate before you compare methods
Method selection is an output, not a starting point. Eight measurements determine which methods remain viable, and each one can invalidate a plan that looked fine on a mailbox-count spreadsheet.
| Criterion | What to measure | Why it changes the method |
|---|---|---|
| Interruption tolerance | Acceptable user-visible outage per mailbox; business hours of the affected teams | Cutover is all-or-nothing for the organization; hybrid moves mailboxes in batches with coexistence intact |
| Mailbox size profile | Count of mailboxes above 100 GB, largest single mailbox | Above 100 GB per user, Microsoft’s large-mailbox workflow and its archive prerequisites apply |
| On-premises archive size | Largest on-premises archive in gigabytes | An on-premises archive over 240 GB cannot be onboarded with the retention-policy approach |
| Shared and resource mailboxes | Count, size, archive status, permission holders | Licensing triggers and permission recreation differ from user mailboxes |
| Legal hold and retention | Mailboxes on hold; retention policy owners; compliance contacts | Holds must be synced to Microsoft 365 and the target MailUser objects must carry the required hold state |
| Hybrid readiness | Exchange version, Entra Connect, hybrid wizard completion, certificate, migration endpoint | Without working hybrid and an endpoint, batch-based native migration cannot run |
| Throughput and window | Link bandwidth, throttling observed in practice, nightly migration window | Batch size and duration follow observed throughput, not theoretical line rate |
| Rollback tolerance | Whether a half-migrated batch is recoverable in place | Batch methods can be checked before completion; cutover cannot be partially undone |
Two of those rows deserve a priority label of their own. The 240 GB on-premises archive limit is a go/no-go gate, not a sizing detail: it invalidates one specific native approach and forces a different content-placement decision. Legal holds are a compliance gate, not a technical one, and they need the legal team’s sign-off before a batch is scheduled.
Who this plan suits, and who should stop before scheduling
The self-selection test matters before any feature comparison. A better tool does not fix an estate that should not run this procedure.
| This plan fits | Pause or change approach |
|---|---|
| Estates with mailboxes above 100 GB, archive-heavy executives or legal teams, and mixed mailbox sizes | Small, simple estates under roughly 150 mailboxes with weekend tolerance: a cutover is faster and cheaper |
| Organizations that can run hybrid coexistence and want free/busy, shared calendars, and a unified address list across both environments | Organizations with no verified backup, no assigned target licenses, insufficient bandwidth, or no administrative bench |
| Tenants with shared mailboxes, resource mailboxes, and permission dependencies that must survive cutover | Compliance models that require data to remain on-premises: validate a different architecture first |
| Teams that can staff a pilot, a help desk surge, and staged production batches over several weeks | Teams planning to push an on-premises archive over 240 GB through the retention-policy workflow: change method before booking a date |
Method and archive fit: what each approach is for, and where it breaks
Keep three concepts separate, because conflating them can send a migration plan sideways. Cutover, staged, and hybrid are methods. PowerShell cmdlets and third-party utilities are tooling. Retention policies, autoexpanding archive, and XML mappings are content-placement mechanisms that run underneath a method.
| Approach | Best fit | Where it breaks |
|---|---|---|
| Cutover | Small, straightforward estates; a few days of delivery inconsistency acceptable while DNS propagates | All-or-nothing: you cannot move a test group first, and failure can require organization-wide rollback |
| Staged | Legacy Exchange environments moving mailboxes in groups by date or department | Not the modern path for Exchange 2016/2019 estates; coexistence is limited compared with hybrid |
| Hybrid | Enterprise estates needing coexistence, batch control, and per-batch verification | Requires directory sync, a working hybrid configuration, a certificate, and a functioning migration endpoint |
| Retention policies plus autoexpanding archive | On-premises mailboxes over 100 GB where cloud archives can be provisioned in advance | On-premises archives over 240 GB are out of scope for this approach |
| Large Mailbox Onboarding with XML mappings | Very large mailboxes needing explicit content distribution across primary, main archive, and auxiliary archive locations | PowerShell-only in Microsoft’s current documentation; users with only a primary mailbox must first be converted to a primary-plus-archive or remote-archive scenario |
Microsoft’s large-mailbox guidance defines the threshold it is written for: large amounts of Exchange user data, defined as more than 100 GB per user. Before any of that workflow can run, cloud archives must be provisioned for users and autoexpanding archive must be enabled at the organization level.
The XML mapping route carries a much larger stated capacity and several constraints. Per Microsoft’s LMO documentation, the resultant cumulative mailbox size can reach up to 1.6 TB: 100 GB of primary mailbox plus 1.5 TB of archives, including a 100 GB main archive. That same document makes the operational trade-off explicit. Users who already have both a primary and an on-premises archive get a simpler restart and cleanup path, with automatic auxiliary archive provisioning, but archive content is not visible through Exchange Online during the migration. Users whose archive already lives in Exchange Online keep archive visibility before, during, and after the move, at the cost of more complex cleanup if a batch has to be recreated with different mappings.
That is a real planning fork. Teams that expect to troubleshoot archive contents mid-migration need the remote-archive scenario; teams that want restart flexibility need the on-premises-archive scenario. Decide it per user population, not once for the whole tenant.
Total cost and dependencies: the drivers, not a fake number
No editorially honest total exists without a current licensing quote from Microsoft. What you can do is price the drivers and stop being surprised by them.
- License and archive entitlements. Every migrated mailbox needs a target license, and archive functionality may need a higher tier. One consultancy states that shared mailboxes under 50 GB without archive do not require a license, while those over 50 GB or using archive functionality require Exchange Online Plan 2: a vendor statement you should confirm against current Microsoft licensing before budget approval.
- Archive storage decisions. Mailboxes above 100 GB may need content relocated into cloud archives before the primary mailbox can be onboarded at all, which adds planning and processing time to the schedule.
- Bandwidth and migration throughput. Measure throughput during the pilot and size later batches from that observed rate. Service throttling shapes practical capacity, so plan around measured performance rather than theoretical line rate.
- Coexistence infrastructure. Directory synchronization, hybrid configuration, certificates, and a functioning migration endpoint are prerequisites, not optional extras.
- Backup, both sides. A verified backup of the source environment before the first batch, and a cloud-side backup or retention plan after cutover.
- Staffing and support. Pilot triage, off-peak batch supervision, help-desk coverage during finalization windows, and a post-migration support period.
- Tooling. Native PowerShell is free but time-intensive; third-party utilities trade licensing cost for reduced scripting overhead.
Prerequisites that must be true before the first production batch
Prerequisites
- Complete mailbox inventory with size, archive size, mailbox type, and legal-hold state for every mailbox, shared mailbox, and resource mailbox.
- A verified backup of the on-premises Exchange environment, tested for restore: not merely scheduled.
- Target Microsoft 365 licenses assigned, including archive entitlements and any shared-mailbox exceptions.
- Cloud archives provisioned for every mailbox being migrated, with autoexpanding archive enabled at the organization level.
- Legal-hold inventory reviewed with compliance, and holds confirmed as syncing to the target MailUser objects.
- Hybrid configuration complete with a valid certificate, and a working migration endpoint that Exchange Online can reach.
- MRS proxy enabled on the Exchange Web Services virtual directory and validated before the first batch.
- DNS time-to-live lowered in advance so MX, Autodiscover, and SPF changes propagate quickly at cutover.
- Transaction-log capacity sized for the destination on-premises database during preparation moves; Ali Tajran’s Exchange guidance estimates roughly 1 GB of transaction logs per 1 GB of mailbox data moved. Do not move more mailbox data than you have log space to absorb.
- A named pilot group of IT staff and cooperative power users, plus a communication plan and help-desk coverage window.
Two temporary on-premises changes are worth planning in advance if you are also moving mailboxes between on-premises databases as part of preparation: circular logging and search-indexing changes can make local moves easier to run, but must be reverted afterwards; disabling indexing temporarily removes user search. Move arbitration and audit-log mailboxes off any database you intend to decommission before you decommission it.
The ordered migration procedure: from criteria to verified cutover
Run these in sequence. Each step produces a decision or an artifact the next step depends on, and no step should be skipped because the previous batch “looked fine.”
- Classify the estate and record the constraints. Pull mailbox and archive sizes with
Get-MailboxandGet-MailboxStatistics, then flag every mailbox above 100 GB and every on-premises archive above 240 GB. Those two lists determine which methods and content-placement mechanisms are still on the table. - Choose the method and the content-placement mechanism separately. Select hybrid for coexistence at enterprise scale, and decide per population whether large mailboxes go through retention policies or LMO with XML mappings. For LMO, users who have only a primary mailbox must be converted to the primary-plus-archive or remote-archive scenario before migration is possible.
- Close every prerequisite gap before the first batch. Backup verified, licenses assigned, cloud archives provisioned, autoexpanding archive enabled organization-wide, DNS TTL reduced, hybrid and migration endpoint working, MRS proxy validated with
Get-WebServicesVirtualDirectoryusing the procedure’s MRS proxy check. - Sync legal holds and collect compliance sign-off. Confirm that every on-premises hold is reflected in Microsoft 365 and that the target MailUser objects carry the required hold state. No batch moves until the compliance owner has signed off in writing.
- Run the pilot batch with autocomplete disabled. Create the batch with
New-MigrationBatchusing-AutoComplete:$falseso nothing finalizes until you inspect it. Validate withGet-MigrationBatchandGet-MigrationUser, and measure the actual throughput for sizing later batches. A procedural walkthrough of the batch sequence covers those commands and the completion step. - Size production batches from pilot throughput and schedule them off-peak. Use the observed rate per endpoint rather than a theoretical ceiling, keep batches inside the migration window, and watch service throttling rather than fighting it. Off-peak and weekend windows are the standard mitigation for throttling.
- Verify each batch before completing it. Confirm batch status, mail flow in both directions, Autodiscover resolution, shared-mailbox access and Send As or Send on Behalf permissions, legal-hold state, and archive visibility for the scenario you chose. Complete with
Complete-MigrationBatchonly after those checks pass. - Reconfigure clients and permissions. Publish the Autodiscover redirect through Group Policy where needed, flush DNS and restart Outlook on affected machines, and recreate any permissions that did not carry across. Confirm free/busy and calendar sharing between migrated and not-yet-migrated users.
Verification, recovery, and the conditions that stop a bad cutover
Completion is irreversible in the practical sense. Microsoft’s large-mailbox documentation spells out the reason to care: deleted-item retention in Microsoft 365 is 14 days, with a maximum of 30, and when a mailbox is migrated, items beyond that limit in mailboxes that are not on hold are removed. The same guidance warns that once a recoverable item lands in the cloud archive, users can no longer restore it with the “recover deleted item” feature from the primary mailbox, so retention policies should move only items older than the on-premises deleted-item retention window. Complete a batch whose recoverable-items policy you have not reviewed, and content can disappear before anyone notices.
Verify the result
Get-MigrationBatchshows the expected status andGet-MigrationUserlists no failed users for the batch.- Test messages arrive and send in both directions between migrated and on-premises users.
- Autodiscover resolves correctly from outside the network and Outlook connects without a manual profile rebuild.
- Shared mailbox access, Send As, and Send on Behalf permissions match the pre-migration baseline.
- Legal-hold state is present on the target objects and confirmed by the compliance owner.
- Archive content is visible to users in the clients you support, consistent with the scenario you chose.
- Help-desk ticket volume is at or near baseline, with no cluster of connectivity or missing-mail reports.
- Source mailboxes remain intact and recoverable, and the restart or cleanup path is documented.
Outlook prompts for a new profile or cannot connect after finalization
Autodiscover is pointing at the wrong target. Check the DNS records and any Group Policy Autodiscover redirect, flush DNS on the client with ipconfig /flushdns, and restart Outlook. If only some machines fail, compare their policy objects before touching tenant configuration.
Mail is not flowing after the MX change
Propagation is the usual cause; verify TTL values were lowered in advance. Also check for forwarding loops and forward-to-self rules, and disable dual delivery temporarily while you diagnose. Cross-premises connectors should be tested before the batch, not during it.
A migration batch stalls or times out
Confirm the MRS proxy is enabled and reachable, then check whether throttling is the limiter. Reducing batch size, moving the window further off-peak, and splitting oversized mailboxes across batches addresses most stalls. Corrupt items in old, large mailboxes can also interrupt a batch, so expect per-user failures rather than a clean sweep.
Shared mailbox permissions are missing after migration
Recreate Send As and Send on Behalf explicitly in the target environment and re-verify membership. Permission mapping across tenants and hybrid boundaries is not guaranteed to carry every grant, and full-access rights on shared mailboxes are a common gap.
Conditions that change the verdict
Danger
Three conditions should stop a scheduled migration: an on-premises archive above the supported retention-policy ceiling queued for that workflow, mailboxes on legal hold without verified hold synchronization, and no tested restore of the source environment. Each one turns a recoverable batch into an unrecoverable one.
| Condition | What it changes |
|---|---|
| On-premises archive exceeds the retention-policy limit | The retention-policy approach is not supported for that mailbox; move to a different content-placement method before committing to a date |
| Mailbox content exceeds cumulative capacity | Content must be split across multiple Microsoft 365 mailboxes or reduced; there is no unlimited archive tier |
| Mailbox not on hold with old recoverable items | Items beyond the deleted-item retention window are removed during migration; review retention policies with compliance first |
| Estate small and simple enough for cutover | Cutover is faster and cheaper, provided a weekend of disruption and organization-wide rollback risk are acceptable |
| Compliance model requires data to stay on-premises | Stop and validate a different architecture; cloud migration is the wrong answer regardless of method quality |
| Any claim of guaranteed zero downtime | Reject it. Coexistence reduces disruption and batch verification contains it; neither eliminates user-visible interruption |
Tooling decisions: PowerShell, native tooling, or a third-party utility
Native PowerShell covers the whole procedure described above. Large Mailbox Onboarding with XML mappings currently runs through PowerShell cmdlets rather than an automated interface. The cost is operator time: batch creation, validation, and per-batch verification all run through commands that someone has to own, review, and log.
Utilities earn their place when the estate is heterogeneous, when scripting capacity is thin, or when granular scheduling and reporting would otherwise consume the project window. Evaluate them against the native constraints you have already measured (capacity ceilings, archive limits, throttling behaviour) and require a pilot result on your own data. A third-party exchange migration tool can reduce scripting overhead, but no vendor claim substitutes for your pilot batch, and vendor-published comparisons are not independent evidence of superiority.
Whatever you choose, the post-migration workload is where quiet costs accumulate: profile fixes, DNS flushes, permission re-grants, and ticket triage. Automating those routine steps is a sensible next investment once the batches are stable, and improving business operations by automating workflows covers the general pattern for help-desk and validation handoffs.
Stellar Migrator for Exchange: An Alternative for Large-Scale Mailbox Migration
For organizations looking for an alternative to managing Exchange migrations entirely through native Microsoft methods and manual PowerShell workflows, Stellar Migrator for Exchange offers a dedicated solution for migrating mailboxes from on-premises Exchange Server to Microsoft 365. It supports Exchange Server 2010–2019 and Exchange Server Subscription Edition (SE), along with Microsoft 365 tenant-to-tenant migration scenarios.
Its capabilities include automatic and CSV-based mailbox mapping, batch and parallel migration, scheduling, incremental migration, priority-based processing, real-time progress monitoring, and detailed migration reports. These features help IT administrators organize migration activities, track mailbox status, identify errors, and validate results throughout the migration process. Before deployment, organizations should test the software against their mailbox volumes, infrastructure, and migration requirements to determine its suitability for their environment.
Where to start this week
Pull the inventory before you take another vendor call. Two numbers from that spreadsheet (the largest on-premises archive and the count of mailboxes above 100 GB) will tell you more about your migration plan than a product demonstration. If the biggest archive clears 240 GB, the retention-policy approach is out for that mailbox. Record that constraint in the step-one inventory, then settle the content-placement choice in step two before you compare methods for that population. If most mailboxes sit under 50 GB and the estate is a few dozen users, a cutover next weekend can beat a twelve-week project.
For everything in between, the schedule is bounded by verification. Each production batch buys speed only if you verify every gate from the previous one (mail flow, permissions, holds, and archive visibility) before completing it. Keep the source environment recoverable until the last check passes, and treat the source-retention period as the real rollback budget. Minimal disruption comes from that gating discipline, not from a tool added at the end.
💬 Comments