How to Create a Migration Endpoint in Office 365

Step-by-Step Guide — Endpoint Types, Prerequisites, PowerShell, Concurrency & Troubleshooting

What Is a Migration Endpoint?

A migration endpoint is a configuration object stored in Exchange Online that holds everything Microsoft 365 needs to reach your source mail system: the remote server address, the credentials of an admin account with access to source mailboxes, and two throttling values that govern how many mailboxes can be in motion simultaneously.

When a migration batch starts, Exchange Online reads the endpoint to determine where to connect, how to authenticate, and how many simultaneous connections to open. Without a valid endpoint, the migration service has no path to the source and will fail immediately — before any data moves.

Think of an endpoint as a persistent connection profile. You create it once and reuse it across multiple migration batches. If you are migrating from Exchange servers in different geographic locations, or want to distribute load across several source servers, you can create separate endpoints for each and assign batches accordingly.

Migration Endpoint Types in Office 365

Each migration scenario uses a different protocol to move data from the source, and the endpoint type tells Exchange Online which protocol to use. Selecting the wrong type is one of the most common reasons the connection test fails — for example, choosing Exchange Remote for an IMAP server will cause Office 365 to look for an MRS Proxy endpoint that does not exist.

 Important: Microsoft retired Staged Outlook Anywhere onboarding on May 8, 2025. Organizations that did not complete staged migrations before that date must use the hybrid remote onboarding process instead.

Exchange Remote (ExchangeRemoteMove)

Used for hybrid migrations where the on-premises Exchange server (2010 SP3 or later) has MRS Proxy enabled. Highest-performance endpoint type — data moves directly using the native MRS protocol.

Outlook Anywhere

Used for cutover and staged migrations from Exchange 2003–2016. Uses RPC over HTTP. MRS Proxy is not required.

IMAP

Used for any IMAP-compatible source: Gmail, Zimbra, Zoho Mail, Yahoo, Rackspace, or any provider that exposes an IMAP port. Only email and folder structure migrate — calendars and contacts require a separate process.

Google Workspace

Uses the Gmail API, enabling email, contacts, and calendar items to migrate together. Requires a Google service account with domain-wide delegation and specific API scopes in the Google Admin console.

Why Migration Endpoints Are Required

Microsoft 365 is a cloud service with no direct visibility into your on-premises or third-party mail environment. A migration endpoint bridges that gap — it tells Exchange Online where the source system lives, how to authenticate to it, and how aggressively to pull data.

Without an endpoint, the Exchange Online migration service cannot initiate any connection to the source. There is no fallback or default path. Every migration type that uses the native framework — hybrid, cutover, staged, IMAP, and Google Workspace — requires a configured endpoint before the first migration batch can be created.

Endpoints also serve a throttling function. The concurrency values stored on each endpoint prevent the source server from being overwhelmed during a large migration. A source Exchange server that handles its normal workload reliably can still be destabilized by dozens of simultaneous migration connections if no throttling is applied.

Common Migration Endpoint Problems

Most endpoint failures fall into one of five categories. Understanding these upfront saves significant troubleshooting time.

MRS Proxy Not Enabled

MRS Proxy is disabled by default on all on-premises Exchange servers. Attempting to create an Exchange Remote endpoint without enabling it first will fail at the connection test — even if the network path and credentials are correct.

EWS Not Externally Accessible

The Exchange Web Services URL must be reachable from Microsoft's IP ranges over the internet. An Exchange server on an internal network segment with no external publishing cannot be used as a migration endpoint source without additional infrastructure changes.

SSL Certificate Problems

The SSL certificate on the source Exchange server must be issued by a public certificate authority, must not be expired, and must include the server's EWS FQDN in the Subject Alternative Name field. Self-signed and internal CA certificates cause the connection test to fail.

Credential Issues

Migration endpoints store credentials at creation time and do not automatically refresh when a password changes or expires. A mid-migration password change, account lockout, or MFA policy applied after the endpoint was created will all cause active migrations to fail silently.

Concurrency Misconfiguration

Setting concurrency too high overloads the source server, causing timeouts and stall-retry cycles. Setting it too low unnecessarily queues mailboxes and extends the migration window. Correct concurrency requires a pilot batch followed by incremental adjustment.

Native Migration Endpoint vs EdbMails

Every problem described in the previous section is an endpoint problem. EdbMails eliminates them entirely by managing its own connections to both source and target environments. No endpoint to create, no MRS Proxy to enable, no EWS URL to publish, no SSL certificate to reissue, and no service account to configure in Google's Admin console.

The table below shows how each migration scenario compares between Microsoft's native endpoint approach and EdbMails.

 Note: EdbMails migrations do not require any endpoint configuration in Exchange Online. Sections 6 and 7 apply only to Microsoft's native migration framework.

How to Create a Migration Endpoint in Exchange Online

You can create migration endpoints through the Exchange Admin Center at admin.exchange.microsoft.com or via Exchange Online PowerShell.

Prerequisites Before Creating an Endpoint

For Exchange Remote endpoints:

• Enable MRS Proxy on the on-premises Exchange server — disabled by default.
• Confirm Exchange Web Services external URL is accessible from the internet via testconnectivity.microsoft.com.
• Ensure the SSL certificate is from a public CA, not expired, and includes the server FQDN in the SAN field.
• Assign ApplicationImpersonation rights to the migration admin account.

Enable MRS Proxy:

Assign ApplicationImpersonation:

For IMAP Endpoints

• Confirm IMAP port and SSL configuration (port 993 with SSL is standard; some providers use 143 with STARTTLS).
• Prepare a credentials CSV with each user's IMAP username and password.

For Google Workspace Endpoints

• Create a Google service account with domain-wide delegation in the Google Admin console.
• Enable the required API scopes. Missing scopes cause authorization errors during the connection test.
• Have the service account email, private key file, and a Google Workspace admin email ready.

Creating an Endpoint in the Exchange Admin Center

Sign in to admin.exchange.microsoft.com, navigate to Migration > Endpoints, click New endpoint, and select the appropriate endpoint type.

For an Exchange Remote endpoint, the wizard asks for an on-premises email address (for autodiscovery), the migration admin account, and the account password. If auto-detection fails, enter the Remote MRS Proxy server FQDN manually. In multi-server environments, point to an individual server rather than a load balancer.

Creating an Endpoint with PowerShell

Connect to Exchange Online first:

Exchange Remote (Hybrid)

IMAP

Verify the endpoint:

Test before running a live migration:

A successful result returns Result: Success. Repeat this test after any network change, certificate renewal, or firewall update.

Editing and Deleting Migration Endpoints

Migration Endpoint Concurrency Settings Explained

Every migration endpoint carries two throttling values that control how data flows through it. Getting them wrong in either direction has real consequences.

MaxConcurrentMigrations

Controls how many mailboxes can be in their initial bulk data copy phase simultaneously. Start at the default of 20, run a pilot batch, monitor the source server's CPU and IIS connection logs, and increase incrementally. Most environments reach a practical ceiling between 30 and 60.

MaxConcurrentIncrementalSyncs

When you complete a batch, every mailbox needs a final incremental sync simultaneously. Raise this value before triggering completion on any large batch:

Set this to at least 25–30% of the batch size you are about to complete. Reduce it again afterward for remaining batches.

Why Higher Is Not Always Faster

Increasing concurrency beyond what the source server can sustain causes timeouts and stall-retry cycles. The result is a migration that is slower overall than it would have been at a lower, sustainable value. If you see frequent StalledDueToSource codes, reduce concurrency rather than increasing it.

How to Diagnose and Fix Migration Endpoint Errors

Common Errors During Endpoint Creation

"Failed to connect to the remote server"

The server FQDN is not reachable from Office 365's IP ranges, or MRS Proxy is not enabled. Run the Exchange Web Services Connectivity test at testconnectivity.microsoft.com before retrying.

"The credentials didn't work"

Verify account format — Outlook Anywhere expects domain\username; Exchange Remote accepts UPN format. Check for account lockout from repeated failed attempts. Confirm Basic authentication is not disabled:

"The certificate is not valid"

The certificate must be from a trusted public CA, not expired, and include the server FQDN in the SAN field. Self-signed certificates always fail this check in production environments.

"HCW8078" during the Hybrid Configuration Wizard

MRS Proxy not enabled, or EWS external URL not configured. Create the endpoint manually via PowerShell rather than re-running the wizard.

Endpoint shows "NeedsToConnect"

Credentials are no longer valid — password expiry, account lockout, or MFA policy applied after endpoint creation. Update without deleting:

To prevent mid-migration failures: use a dedicated service account with a non-expiring password excluded from MFA policies.

Stall States During Migration

Stall states are not failures. Mailboxes will resume automatically once the underlying condition clears. Identify them with: