Exchange hybrid remote move migration: endpoints, batches and completion

A hybrid remote move migration moves existing on-premises Exchange mailboxes to Exchange Online without re-creating them: Exchange Online pulls each mailbox through the MRS Proxy endpoint on your Exchange servers, keeps it in sync, and at completion converts the on-premises mailbox into a remote mailbox that points to the cloud. To run one, enable MRS Proxy on every Mailbox server, test and create a migration endpoint, create a migration batch from a CSV file with the target delivery domain contoso.mail.onmicrosoft.com, and complete the batch when you're ready to switch users over.

Who this is for and what you will have at the end

This guide is for Exchange administrators who already have a full hybrid deployment between on-premises Exchange (2016, 2019 or Subscription Edition) and Exchange Online, and now need to move mailboxes. It covers onboarding (on-premises to cloud) in detail and offboarding (cloud back to on-premises) briefly.

At the end you will have:

• MRS Proxy enabled and reachable from Exchange Online.
• A tested migration endpoint with sensible concurrency.
• Migration batches built from CSV files, with controlled completion times.
• A verification routine and a troubleshooting table for the errors that block hybrid moves.

If the Hybrid Configuration Wizard (HCW) failed while setting up the hybrid relationship, fix that first with the HCW errors guide for Exchange Server SE. If you are moving mailboxes because Exchange 2016 or 2019 is out of support, the end of support planning guide explains where the move fits in the bigger plan.

How a remote move works

A few components do all the work:

When you start moves from the Exchange Online EAC, onboarding is a pull: Exchange Online connects to your MRS Proxy and copies the data. Offboarding is a push from Exchange Online to the on-premises MRS Proxy. Either way, the MRS Proxy endpoint must be enabled on your on-premises Mailbox servers.

At completion, Complete-MigrationBatch runs a final incremental sync, points the user's Outlook profile at the new location and converts the source mailbox to a mail-enabled user. Mailbox moves run at a lower priority than client access and mail flow, so queued periods are normal.

Prerequisites

• A full hybrid deployment configured with the HCW. Remote move migrations require it.
• Permissions. On-premises, the account used by the endpoint needs Organization Management or Recipient Management for hybrid mailbox moves. Enter it in domain\user format (for example contoso\migadmin). In Exchange Online you need an account that can run the migration cmdlets.
• Publishing. Exchange Online must reach /ews/mrsproxy.svc on your servers over TCP 443 without pre-authentication at a reverse proxy. Mailbox migrations use NTLM against this endpoint, and pre-authentication isn't supported.
• Accepted domains. Every SMTP domain on the mailboxes you move must be an accepted, verified domain in the tenant. Missing domains are a common reason moves fail to start.
• Licensing plan. Assign the Exchange Online license after the mailbox has moved; you then have 30 days to assign it.
• Exchange Online PowerShell and the Exchange Management Shell on-premises.

Step 1: Enable MRS Proxy on every Mailbox server

Enable the endpoint on all Mailbox servers, not just the one in your public DNS. Moves can fail if it's disabled on any of them, and new servers you add later need it too. In the Exchange Management Shell:

Get-WebServicesVirtualDirectory | Set-WebServicesVirtualDirectory -MRSProxyEnabled $true
Get-WebServicesVirtualDirectory | Format-Table -Auto Identity,MRSProxyEnabled

In the on-premises EAC, the same setting is Servers > Virtual Directories > select the EWS virtual directory > Edit > General > Enable MRS Proxy endpoint.

Microsoft's hybrid migration troubleshooter also checks WS-Security authentication on the EWS virtual directory, because hybrid endpoints rely on it:

Get-WebServicesVirtualDirectory -Identity "EX01\EWS (Default Web Site)" | Format-List Server,MRSProxyEnabled,WSSecurityAuthentication

Microsoft's guidance is to keep MRS Proxy disabled when you don't perform cross-forest moves or remote move migrations, to reduce the attack surface. Offboarding moves need it too, so only turn it off once you no longer expect moves in either direction.

Step 2: Test connectivity from Exchange Online

Before you create anything, check that Exchange Online can reach the MRS Proxy with your credentials. Connect to Exchange Online PowerShell and run:

Connect-ExchangeOnline -UserPrincipalName admin@contoso.com
$onprem = Get-Credential contoso\migadmin
Test-MigrationServerAvailability -ExchangeRemoteMove -RemoteServer mail.contoso.com -Credentials $onprem

A failure here is far easier to diagnose than a failed batch. The usual causes are pre-authentication or an intrusion detection system on the perimeter device, a firewall that doesn't allow the Exchange Online IP ranges, and MRS Proxy disabled on the server that answers.

Step 3: Create or check the migration endpoint

The HCW creates a migration endpoint for you, typically named Hybrid Migration Endpoint - EWS (Default Web Site), and Microsoft calls it the preferred method. Find it with:

Get-MigrationEndpoint | Format-List Identity,RemoteServer,MaxConcurrentMigrations,MaxConcurrentIncrementalSyncs

If you need an additional endpoint (for example, a second datacenter with its own MRS Proxy namespace), create it in the EAC under Migration > Endpoints > + Add with the Exchange Remote type, or in PowerShell:

New-MigrationEndpoint -Name "MRS-DC2" -ExchangeRemoteMove -RemoteServer mrs2.contoso.com -Credentials $onprem `
    -MaxConcurrentMigrations 20 -MaxConcurrentIncrementalSyncs 10
Test-MigrationServerAvailability -Endpoint "MRS-DC2"

MaxConcurrentMigrations caps how many mailboxes the endpoint migrates during initial sync and MaxConcurrentIncrementalSyncs caps incremental syncs per endpoint. The EAC wizard proposes 20 and 10, while the New-MigrationEndpoint reference lists defaults of 100 and 20 when you don't specify them, so set both explicitly if you create the endpoint in PowerShell. The source servers serve your users and the migration at the same time, so change these values deliberately and watch the servers afterwards.

Step 4: Plan batches and build the CSV

A remote move CSV needs a single EmailAddress column:

EmailAddress
ana@contoso.com
ben@contoso.com
finance-shared@contoso.com

Practical batching rules that follow from how moves work:

• Group users who work together (delegates, shared mailboxes they open) so they complete together.
• Spread users across source databases and servers so no single server carries the whole batch.
• Put very large mailboxes in their own batch; they take longer and shouldn't hold back everyone else.
• For users who also have an archive mailbox, New-MigrationBatch -PrimaryOnly moves only the primary mailboxes and leaves the archives where they are. Don't use the switch for users without archives.

Microsoft publishes these onboarding duration estimates for moves from on-premises Exchange:

Step 5: Create and start the batch

In the Exchange admin center

1. Go to Migration and select Add migration batch.
2. Enter a unique batch name and choose Migration to Exchange Online as the mailbox migration path.
3. Choose Remote move migration as the migration type and select Next on Prerequisites for remote migration.
4. Select your migration endpoint.
5. On Add user mailboxes, choose Migrate from CSV file (or Manually add users to migrate for a few users).
6. Select the Target delivery domain, for example contoso.mail.onmicrosoft.com.
7. On Schedule batch migration, add at least one report recipient, choose how to start the batch, and choose how to end it: manually, automatically, or automatically after a date and time.
8. Pick a time zone for report entries (UTC by default), select Save and then Done.
9. If the batch didn't start automatically, select it on the Migration batches page, choose Resume migration and then Confirm. Its status should change to Starting.

If you choose to complete the batch manually, Exchange Online syncs each mailbox to about 95% and keeps it there with periodic syncs; the remaining 5% moves when you select Complete this migration batch. That's the normal way to pre-stage data days ahead of a cutover weekend.

In Exchange Online PowerShell

$csv = [System.IO.File]::ReadAllBytes("C:\Migration\Finance.csv")
 
$batch = New-MigrationBatch -Name "Finance-Wave1" `
    -SourceEndpoint "Hybrid Migration Endpoint - EWS (Default Web Site)" `
    -TargetDeliveryDomain contoso.mail.onmicrosoft.com `
    -CSVData $csv `
    -NotificationEmails admin@contoso.com `
    -CompleteAfter "10/24/2026 9:00 PM" -TimeZone "W. Europe Standard Time"
 
Start-MigrationBatch -Identity $batch.Identity.Name

Notes on these parameters:

• TargetDeliveryDomain is required for remote move onboarding batches.
• CompleteAfter delays completion while data copies. In Exchange Online PowerShell a value without a time zone is treated as UTC; add -TimeZone with a Windows time zone key name, or include an offset such as -0700.
• -AutoStart starts the batch immediately instead of calling Start-MigrationBatch. -AutoComplete finalizes each mailbox as soon as initial sync finishes, which is rarely what you want for planned cutovers.
• BadItemLimit and LargeItemLimit are deprecated in Exchange Online. Review the Data Consistency Score and skipped items instead.

Step 6: Monitor the batch

Get-MigrationBatch -Identity "Finance-Wave1"
Get-MigrationUser -BatchId "Finance-Wave1" | Get-MigrationUserStatistics
Get-MigrationUserStatistics -Identity ana@contoso.com -IncludeReport | Format-List Status,Error,Report
Get-MoveRequest -Identity ana@contoso.com | Get-MoveRequestStatistics

Get-MigrationUser -Status accepts values such as Queued, Syncing, Synced, Failed, Completing and Completed, which makes it easy to list only the users that need attention. Microsoft advises not to start troubleshooting a queued or slow move until there has been a long period (such as 8 hours) with no progress, because moves yield to other workloads under load.

If skipped items are found, review them before completion:

Get-MigrationUserStatistics -Identity ana@contoso.com -IncludeSkippedItems |
    Select-Object -ExpandProperty SkippedItems | Format-List DateReceived,Subject
Set-MigrationUser -Identity ana@contoso.com -ApproveSkippedItems

Step 7: Complete, license and clean up

When users are Synced and you're inside the change window, complete the batch (or let CompleteAfter do it):

Complete-MigrationBatch -Identity "Finance-Wave1"

In Exchange Online this sets the batch's CompleteAfter to the current UTC time. Two behaviors to know: a CompleteAfter set on individual users overrides the batch value, and if you run the cmdlet again within 8 hours of the batch being signaled for completion, the service may not reprocess the request. If the batch looks stuck after completion, unapproved skipped items are the first thing to check. If the batch ends with a status of Completed with Errors, run Start-MigrationBatch in Exchange Online to retry the failed users.

Then:

1. Assign Exchange Online licenses to the moved users (within 30 days).
2. Tell users who rely on Outlook on the web offline that they must turn offline access on again in their browser after the move.
3. Remove the completed batch so the same users can be moved again later without conflicts:

Remove-MigrationBatch -Identity "Finance-Wave1"

Verify the moves

• Get-MigrationBatch shows the batch as Completed.
• In the Exchange Online EAC under Recipients > Mailboxes, the user appears with a mailbox type of Office 365.
• On-premises, the user is now a remote mailbox that routes to the coexistence domain:

Get-RemoteMailbox -Identity ana@contoso.com | Format-List RemoteRoutingAddress,ExchangeGuid

• Send mail between an on-premises user and the moved user in both directions, and check free/busy both ways.

Troubleshooting hybrid moves

Moving mailboxes back on-premises

Offboarding uses the same endpoint as the target. In the EAC choose Migration from Exchange Online, select the endpoint, the users, the target delivery domain (your on-premises domain) and the on-premises target database. In PowerShell:

$csv = [System.IO.File]::ReadAllBytes("C:\Migration\Return.csv")
$off = New-MigrationBatch -Name "Offboard-1" -TargetEndpoint "Hybrid Migration Endpoint - EWS (Default Web Site)" `
    -TargetDeliveryDomain contoso.com -TargetDatabases @("MBXDB01","MBXDB02") -CSVData $csv
Start-MigrationBatch -Identity $off.Identity

Checklist

• Full hybrid is in place and every mailbox domain is an accepted domain.
• MRS Proxy is enabled on every Mailbox server and published without pre-authentication.
• Test-MigrationServerAvailability succeeds against the endpoint.
• Batches are grouped by team, spread across source servers, with large mailboxes isolated.
• Completion is scheduled with CompleteAfter (and TimeZone), or done manually after 95% pre-staging.
• Skipped items are reviewed and approved before completion.
• Licenses are assigned within 30 days; completed batches are removed.
• MRS Proxy is disabled again once no further onboarding or offboarding moves are planned.

References

• Move mailboxes between on-premises and Exchange Online organizations in hybrid deployments
• Use the EAC to move mailboxes
• Use PowerShell to move mailboxes
• Creation of migration endpoints using different methods
• Enable the MRS Proxy endpoint for remote moves
• Remove completed migration batches
• Hybrid deployment prerequisites
• Recipients permissions
• Troubleshoot migration issues in Exchange hybrid
• MigrationPermanentException when moving mailbox
• Microsoft 365 and Office 365 migration performance and best practices
• New-MigrationEndpoint
• New-MigrationBatch
• Test-MigrationServerAvailability
• Complete-MigrationBatch
• Get-MigrationUser
• Get-MigrationUserStatistics