Recover Mailbox after Exchange Migration Failure

Migration State Decision Table

Common Causes of Exchange Migration Failure

Migration infrastructure

Migration Endpoint / MRS Proxy Connectivity Failure: hybrid and cross-forest remote mailbox moves depend on the appropriate migration endpoint and Mailbox Replication Service Proxy configuration. If the endpoint or MRS Proxy is unavailable or incorrectly configured, the mailbox move can fail. See Microsoft's guidance on mailbox moves and MRS Proxy and creating a migration endpoint.

• Network or transient connectivity
• Destination Exchange availability
• Autodiscover / DNS where relevant

Authentication and permissions

• Incorrect credentials
• Insufficient migration permissions
• Authentication configuration
• Access denied

Mailbox/data problems

• Corrupted mailbox items/folders/properties
• Mailbox quota / target provisioning
• Problematic mailbox rules or properties

Migration-state problems

• Failed or stale move request
• Interrupted migration batch
• Incomplete target provisioning

Migration workload/resource constraints or throttling can slow moves or contribute to transient migration issues, depending on the environment - it isn't the default explanation for every delayed migration.

What If Corrupt Mailbox Items Are Blocking the Migration?

Review the migration report first. Depending on the failure and supported Exchange version, administrators may need to correct the affected mailbox/folder condition or use Microsoft-supported move options - see Microsoft's guidance on corrupted items blocking a mailbox migration rather than applying risky PowerShell remediation blindly. This is a separate issue from OST corruption, which is covered later on this page.

Migration Process vs Outlook Synchronization

These are two different processes, and it's worth keeping them separate when diagnosing a problem:

For Outlook synchronization that never completes, diagnose target mailbox availability, network, profile/cache state, mailbox size/cache range and service health. Review the Exchange move state separately - the two are diagnosed differently and resolving one doesn't automatically fix the other.

Method 1: Review the Mailbox Move / Migration Report

Check the report for:

• Current move status
• Completion percentage
• Failure message
• Transient vs permanent failures
• Skipped/problematic items
• Source database/mailbox
• Destination mailbox
• Retry history
• Detailed move report

For native move requests, Get-MoveRequestStatistics -IncludeReport can provide detailed move information.

Method 2: Resolve the Migration Failure and Resume the Mailbox Move

• MRS Proxy / endpoint problem - repair remote-move endpoint.
• Authentication / permission problem - correct access/authentication.
• Quota / provisioning problem - resolve target constraints.
• Corrupt item/folder problem - follow Exchange-supported remediation.
• Network / transient failure - restore connectivity and allow retry/resume.

Don't introduce OST recovery while the server migration itself remains recoverable - it's a distraction from the fix that's actually available.

After identifying and correcting the failure, resume the existing supported move or batch where appropriate. Create a new move only when the existing request cannot or should not be resumed - this avoids unnecessary deletion and recreation of move requests.

What If Exchange Says the User Is Already Being Moved?

• Verify whether an existing move request still exists.
• Determine its actual state.
• Do not blindly create another migration.
• Clean up stale move references only after confirming the request is truly obsolete.

Source vs Destination Validation

Method 3: Recover Missing Data from the Soft-Deleted Source Mailbox

After a mailbox move, Exchange may retain the source mailbox in a soft-deleted state for the mailbox retention period. If users discover missing folders or items after migration, check the retained source mailbox before resorting to OST recovery - see Microsoft's current guidance for Exchange Online or on-premises Exchange.

It's worth distinguishing two different situations here: a migration that failed before completion calls for diagnosing, resolving and resuming or retrying the migration itself. A migration that completed but is missing data calls for comparing source and target, checking the retained soft-deleted source mailbox, and then restoring what's missing. OST recovery is a third-line fallback path for either situation, not the first response to it.

Method 4: Recreate the Outlook Profile After Successful Migration

Use this method only when the destination mailbox exists, the migration is complete, mailbox data is visible server-side, and the remaining issue is Outlook-side access.

1. Open Control Panel (Classic Outlook for Windows).
2. Select Mail.
3. Choose Show Profiles.
4. Create a new Outlook profile.
5. Configure the migrated Exchange or Microsoft 365 account.
6. Start Outlook.

These steps apply to classic Outlook for Windows and don't necessarily carry over identically to new Outlook. In classic Outlook for Windows, an Exchange or Microsoft 365 account using Cached Exchange Mode creates a local OST cache as the mailbox synchronizes.

Synchronization time depends on practical factors: mailbox size, cached-mail range/settings, network throughput, service/server performance, and the amount of changed mailbox data - it isn't automatically down to Exchange throttling.

After creating a new Outlook profile, allow the initial mailbox synchronization to complete before concluding that folders or items are missing locally. Even so, verify server-side mailbox data independently rather than relying only on the new OST - a mailbox that looks empty in Outlook right after profile creation usually just hasn't finished downloading yet.

If Autodiscover appears to connect to a previous server, verify Autodiscover and target mailbox configuration first. Recreate the Outlook profile only when client configuration is confirmed to be stale or incorrect - don't default to clearing profiles automatically.

Method 5: Recover from the OST Only When Server Recovery Is Unavailable

Use this method when:

• Original source mailbox is no longer available.
• Destination does not contain the required data.
• Soft-deleted source mailbox has expired or been purged.
• Usable backup is unavailable.
• A surviving local OST exists.
• Required mailbox content appears in the OST.

The surviving OST may contain locally cached data from the source mailbox, including potentially useful items that are missing from the migrated destination. What is available depends on the Outlook cache state and the last successful synchronization. An OST is a local synchronized cache, not a guaranteed complete backup of the Exchange mailbox - a surviving OST may contain recoverable local mailbox data that is no longer available from the source or destination environment, not the only or definitive copy of anything.

EdbMails can scan, recover and preview an OST without Outlook or the original Exchange profile. Microsoft Outlook with a configured profile is required when exporting recovered OST data to PST. Outlook is not required for direct OST to Microsoft 365 or Exchange migration.

This is where the EdbMails OST to PST Converter comes in - the proper commercial handoff once server-side options are genuinely exhausted.

Native Recovery vs OST Recovery

PST Export vs Direct Exchange / Microsoft 365 Migration

Don't force unnecessary PST staging when direct target migration is supported - if the goal is simply to get the recovered data back into a live mailbox, migrating directly skips a step.

Before Exchange Migration

• Validate Exchange health.
• Verify target provisioning.
• Verify MRS Proxy / migration endpoint for remote moves.
• Confirm migration permissions.
• Validate mailbox quotas.
• Run pilot mailboxes.
• Retain source mailboxes during validation.
• Maintain independent backup where required.
• Monitor move reports.

These practices reduce migration disruption and improve recovery options if a mailbox move fails.

Post-Migration Validation

Validate before removing or purging any source recovery options:

• Mailbox item counts
• Critical folders
• Recent mail
• Contacts
• Calendars
• Archive mailbox where applicable
• User access
• Mail flow
• Outlook connectivity
• Representative mailbox searches

Maintain an appropriate independent mailbox backup and recovery plan for migration projects where business requirements call for rollback or point-in-time recovery. PST export may be useful for selected recovery scenarios, but it shouldn't be treated as the default enterprise safety strategy.

If a mailbox appears empty right after migration, that's not automatically data loss: check the mailbox directly server-side or through web access where applicable, review move completion and the migration report, check whether a soft-deleted source mailbox still exists, and allow Outlook cache synchronization only after server data is confirmed. Treating a display or cache issue as immediate data loss is one of the most common false alarms in this scenario.