Fix Exchange Migration Stuck at 95% Without Data Loss

The migration batch sat at 94 percent for an hour, then ticked to 95 percent, and has been there for six hours. The job isn't failing — Get-MoveRequestStatistics shows it as InProgress, no errors are raised, the source server is healthy. This is the classic Exchange-to-Office 365 stall, and it almost never resolves on its own. The last few percent of any mailbox contains the items MRS deferred earlier because they were difficult, and one or more of them is now hitting a hard limit. The fix is to find out which limit, raise it, and resume.

Why Exchange migrations stick at 95 percent#

The Mailbox Replication Service processes items in batches sorted roughly by likelihood of success. Plain text emails go first, then standard formatted mail, then large attachments, then calendar items with quirks, then contacts and tasks. By design, the last 5 percent of any mailbox is where the difficult items live. Four causes account for almost every stuck batch.

Large items hit the retry loop#

Office 365 enforces a hard 150MB ceiling on individual items. Anything larger gets logged but MRS retries it three times before giving up, and during those retries the overall percentage stops moving. If the mailbox has a single 250MB item, it can eat 30 minutes of progress before MRS marks it as a large-item failure. The message too large fix covers the standalone error in detail.

Corrupt items below the skip threshold#

MRS will skip corrupt items up to the BadItemLimit you set on the move request. The default is 0 — any single corrupt item halts the mailbox. Most migration runbooks set it to 10 or 50, but if you started the batch with the default and the mailbox has even one corrupt calendar item, the job will stall at the moment it tries to read that item. Symptoms include the AutoSuspended state never being reached and the report showing a single bad item logged over and over.

MRSProxy timeouts#

Cross-premises migrations route through MRSProxy on the source Exchange front-end. Its default RPC timeout is 5 minutes per call. For mailboxes with very large folders (think 80,000+ items in Sent Items), a single ICS sync call can exceed that timeout and MRS retries the whole call. The retries compound and the visible percentage stops moving even though the engine is busy. The Exchange migration guide covers MRSProxy preflight in more detail.

Bad items the engine cannot skip without operator action#

Some failure modes — duplicate IPM.Schedule.Meeting.Request items with the same global object ID, or contacts with malformed picture attributes — can't be skipped automatically because they aren't classified as bad items by MRS. They show up as TransientException in the report and trigger indefinite retries. The fix is to identify them via the report and either delete them from the source mailbox or export them separately.

If you're staging a wider Exchange-to-Microsoft 365 move, the Exchange to Office 365 pair guide covers the project sequence end to end, including the limit settings you'd ideally have applied before the batch even started.

Unblocking the stuck batch — step by step#

1. Check the migration report for the actual cause

   Run Get-MoveRequestStatistics -Identity user@domain.com -IncludeReport | Format-List and scroll to the bottom. Read the last 50 log entries. Look for BadItemsEncountered, LargeItemsEncountered, and RpcTimeoutException. The cause is almost always in those three.

2. Raise LargeItemLimit and BadItemLimit on the move request

   Run Set-MoveRequest -Identity user@domain.com -LargeItemLimit 50 -BadItemLimit 50. This tells MRS to skip up to 50 of each rather than stall on them. Microsoft's own guidance considers 50 a safe upper bound for typical mailboxes; if you set it higher than 100, the move switches to AcceptLargeDataLoss mode and you should reconsider whether you want to proceed.

3. Resume the move request

   Run Resume-MoveRequest -Identity user@domain.com. The percentage should immediately start moving as MRS skips the items it was previously retrying. Within 10–15 minutes the mailbox should reach 100 percent and AutoSuspended state if Complete-MigrationBatch hasn't been called yet.

4. Extend MRSProxy timeout if RPC errors persist

   On the source Exchange front-end, edit web.config for the EWS application and raise the MRSProxyMaxConnections and MRSProxyConnectionTimeout values to 900 seconds. Recycle the MSExchangeServicesAppPool. Resume the move request again. This step is only needed for large-mailbox stalls where MRS retries succeed for small items but fail for large ones.

5. Export skipped items to PST for review

   The migration report lists every skipped item ID. Run Search-Mailbox -Identity user -SearchQuery "MessageId:..." -TargetMailbox archive -TargetFolder Skipped for each, or use New-MailboxExportRequest for a bulk export. Hand the PST to the user so they can confirm what was lost.

6. Complete the batch once the count clears

   With the mailbox at 100 percent AutoSuspended, run Complete-MigrationBatch -Identity <batch-name> to finalise the cutover. The MX flip and Autodiscover update happen after this command. Monitor for an hour to confirm the new endpoint is serving the user.

Preventing 95 percent stalls on the next batch#

Set LargeItemLimit 50 and BadItemLimit 50 at the time you create the move request, not when it stalls. There is no downside to having the limits set on a clean mailbox — they only fire if something hits them — and the upside is the job runs unattended to completion. Audit any mailbox over 25GB before queuing it. Run a quick Get-MailboxFolderStatistics and look for folders over 80,000 items. Those are the MRSProxy timeout candidates and they want a pre-batch cleanup.

Have the user empty Deleted Items and Junk Email before the migration. Those folders are the densest source of corrupt items because nothing depends on them. Cutting them out can drop the bad-item count to zero on otherwise problematic mailboxes.

FAQ#

If you're working a broader Microsoft 365 migration, the Office 365 migration guide walks through the same considerations from project start. The email migration troubleshooting hub catalogues the other errors you're most likely to hit.