Update an Exchange Online migration endpoint only after you verify transport connectivity, certificate trust, and the required admin permissions. If any of those checks fail, fix them first instead of changing the endpoint. Bad updates can break active batches, trigger repeated connection failures, and force you to rework migrations you could have kept running. This guide shows the checks to run, the errors they prevent, and the safest way to update the endpoint without restarting the whole migration.
Exchange Online migration endpoint overview
An Exchange Online migration endpoint stores the connection details Microsoft 365 uses to reach the on-premises Exchange source during cutover migration. It does not move mailboxes by itself. It stores the server name, the authentication method, and the trust relationship used for the migration service to connect through Outlook Anywhere.
What changes when you update it
Updating an existing endpoint changes the connection settings while keeping the migration object and any related batches in place. Recreating the endpoint is the larger step. Use that only when the current object is tied to the wrong server, the wrong auth model, or a trust state that cannot be corrected cleanly.
How Outlook Anywhere fits
The migration service uses Outlook Anywhere, also called RPC over HTTP, to connect to on-premises Exchange. For cutover migration, that path usually needs to be working on the source server before an endpoint update can succeed. If Outlook Anywhere is disabled, the endpoint update may save, but the validation test will still fail.
đź“Š Cutover migration is suggested when the on-premises Exchange organization is Exchange Server 2003 or later. Source: Microsoft.
What you need before you update
Have the source server details, the admin account that can edit the migration endpoint, and a trusted certification authority certificate that matches the Exchange services used for the connection. Verify Outlook Anywhere and Autodiscover first. If those checks fail, the endpoint settings are not the real problem.
Permissions and account access
You need Exchange Online permissions that can manage migration endpoints in the Microsoft 365 admin or Exchange admin experience. In practice, use an account with the rights to view and edit migration settings, run endpoint tests, and restart validation. A read-only account cannot fix an endpoint that needs a change.
Certificate and service checks
The certificate must be issued by a trusted certification authority and must cover the Outlook Anywhere and Autodiscover services. Confirm that the subject or SAN matches the names clients and the migration service use. If the source server presents a self-signed or mismatched certificate, trust validation often fails during endpoint updates.
Record and transport checks
Confirm that Outlook Anywhere is enabled on the source Exchange server and that the Autodiscover DNS record is correct for the on-premises namespace you are still using. For cutover migration, Microsoft says the source organization should be Exchange Server 2003 or later, and cutover is intended for fewer than 2,000 mailboxes, with 150 mailboxes or fewer a more reasonable target. (Microsoft Learn)
How do you update the migration endpoint?
First, check the current endpoint settings. Then edit only the fields that still match the on-premises source, such as the server name, authentication method, and certificate trust. If those values no longer match the live Exchange configuration, correct the source configuration before editing the endpoint. Save the update, then rerun validation against the same source server.
Update it in the admin center
- Open Exchange admin center > Migration > Endpoints.
- Select the existing migration endpoint and open Edit.
- Confirm the server name, authentication method, and connection settings.
- Save the change, then run the endpoint validation or connection test.
Update it with PowerShell
- Connect to Exchange Online PowerShell with an account that can manage migration endpoints.
- Run Get-MigrationEndpoint to inspect the current values.
- Use the endpoint edit cmdlet available in your tenant to change only the needed fields.
- Re-run the test command or restart the endpoint validation.
If the endpoint object rejects the change, stop there. Recreate it only after you confirm the source server configuration is correct and the existing object cannot be brought back into alignment.
Why did Exchange Online fail to update the migration endpoint?
Most update failures come from a mismatch between Exchange Online expectations and the source server’s actual settings. Common causes are auth mismatch, certificate trust failure, wrong server name, Outlook Anywhere not enabled, and firewall or TLS blocking. Each one points to a different fix.
Auth mismatch
If the endpoint expects one authentication method and the source server is configured for another, validation fails even when the server is reachable. Check the source Exchange Outlook Anywhere settings and the endpoint’s auth field side by side. If the source auth changed during a hardening project, update the source first.
Certificate trust failure
Trust failures happen when the certificate chain is incomplete, the certificate is expired, or the names do not match the Exchange services in use. Verify that the certificate is trusted by the migration service and that it covers Outlook Anywhere and Autodiscover. If the certificate was replaced, recreate the endpoint only if the old trust record cannot be refreshed.
Wrong server name or disabled Outlook Anywhere
If the endpoint points to the wrong host name, or if Outlook Anywhere is turned off on the source server, the migration service cannot complete its check. Confirm the exact host name on the Exchange server and compare it with the endpoint value. If Outlook Anywhere is not enabled, turn it on before retrying.
Firewall or TLS blocking
Firewall blocks and TLS negotiation failures can surface as connection errors even when DNS resolves correctly. Confirm reachability to the source Exchange endpoint over the required port used by Outlook Anywhere and verify that TLS settings permit the connection. A blocked TLS version or middlebox inspection can break the validation test.
Migration endpoint troubleshooting matrix
Use this matrix to decide whether you can edit the endpoint or need to recreate it. The key question is whether the source Exchange settings still match the endpoint object. If they do, edit. If they do not, fix the source first or recreate the endpoint after the source is corrected.
| Symptom | Likely cause | Validation command or check | Fix |
|---|---|---|---|
| Endpoint update fails with an authentication error | Auth method mismatch between the endpoint and source Exchange | Check Outlook Anywhere auth in EAC or run Get-OutlookAnywhere | Edit the endpoint if the source is correct; otherwise update the source auth first. Edit |
| Connection test fails on certificate trust | Certificate chain not trusted, expired, or missing Outlook Anywhere / Autodiscover coverage | Inspect the cert in Exchange and confirm CA trust on the source namespace | Replace or fix the certificate, then retest. Recreate only if the endpoint still references stale trust data. Often recreate |
| Server cannot be reached by the migration service | Wrong server name in the endpoint | Compare the endpoint host name with the Exchange server namespace | Edit the server name if the source is correct. If the namespace changed, update DNS and source config first. Edit |
| “The connection to the server could not be completed” | Outlook Anywhere disabled, TLS blocked, or firewall rule missing | Run Test-NetConnection to the source host and check Outlook Anywhere status | Enable Outlook Anywhere, open the required path, and retest. Recreate does not fix transport failure. Edit |
| Update works once, then fails again during validation | Autodiscover or certificate name mismatch on the source side | Check Autodiscover DNS and the certificate SAN entries | Fix the source names and cert first; then update the endpoint. Edit |
Suppose the endpoint points to mail.contoso.com but the source server now answers only on exchange.contoso.net. The update may save, then fail the next validation because the service name no longer matches the live certificate. Fix the namespace and certificate together, not one at a time.
Why does the connection to the server could not be completed error happen?
This error usually appears when the migration service can reach part of the path but not the whole Outlook Anywhere connection. The most common reasons are a disabled Outlook Anywhere endpoint, a blocked port or TLS path, or a certificate that the service cannot trust. The error is often connectivity, not migration logic.
Validation sequence to run
- Confirm the source Exchange server is reachable by name from the migration endpoint settings.
- Run Get-OutlookAnywhere and verify it is enabled.
- Check Test-NetConnection to the source host on the Outlook Anywhere path.
- Inspect the certificate chain and subject names.
If those checks pass and the error remains, recreate the endpoint only when the object still carries stale server or auth metadata that cannot be edited cleanly.
What settings does the endpoint use?
The endpoint typically uses four things: the server name, the authentication method, certificate trust, and the transport path. Those values must match the source Exchange system at the moment you validate. If the source changes later, the endpoint may need an update even if the migration batch itself is still healthy.
Server name
The server name should match the host name or namespace exposed by the on-premises Exchange service. A typo, an old load balancer name, or a retired namespace can cause update failures. Use the exact value configured for the source Outlook Anywhere endpoint.
Authentication and certificate trust
The authentication setting must match the source Outlook Anywhere configuration. Certificate trust must line up with a trusted certification authority certificate that covers Outlook Anywhere and Autodiscover. If either one changes, rerun validation before touching batches.
Transport path
Outlook Anywhere, also called RPC over HTTP, is the transport path the migration service expects. It must be enabled on the source Exchange server. For cutover migration, Microsoft also requires the mailbox move workflow to end with license assignment, an Autodiscover DNS record, and an MX record change so mail routes to Microsoft 365 or Office 365 after cutover.
Common mistakes
Editing the wrong object is common. Administrators sometimes change a new endpoint while the active batch still points to the older one. Another mistake is treating MX or Autodiscover updates as endpoint fixes; they are post-migration tasks, not endpoint repair steps.
A common first-timer mistake is to change the MX record before the mailbox moves are complete. That can route some mail to Microsoft 365 or Office 365 while the cutover still depends on the on-premises source. Microsoft warns that mail may continue to route to on-premises mailboxes until the MX record changes.
Skipping certificate validation is another repeat offender. If the certificate does not cover Outlook Anywhere and Autodiscover, the endpoint may fail even when DNS looks right.
What IP addresses or firewall rules does Exchange Online migration use?
Use the source Exchange server’s published Outlook Anywhere path rather than a fixed “migration IP list.” The migration service needs outbound reachability from Microsoft 365 to the on-premises Exchange namespace, plus any firewall rule that permits the Outlook Anywhere connection and TLS negotiation. Confirm the exact port and allowlist with your network team before rerunning validation.
Say your firewall team opened the wrong port but left TLS inspection in place. The endpoint still fails because the service can resolve the host name yet cannot complete the handshake. In that case, correct the rule set and retest; changing the endpoint will not repair the network path.
Frequently asked questions
How do you update the Exchange Online migration endpoint?
Open Exchange admin center > Migration > Endpoints, select the existing endpoint, and edit only the server name, authentication, or other values that still match the source. In PowerShell, run Get-MigrationEndpoint first, then update the object with the available edit cmdlet in your tenant and rerun validation.
What permissions are required for an Exchange Online migration endpoint?
You need an account that can view, edit, and validate migration settings in Exchange Online. A read-only account cannot change the endpoint. Use an admin account that can open Exchange admin center > Migration > Endpoints or connect to Exchange Online PowerShell and run the migration endpoint cmdlets.
What settings does the migration endpoint use in Exchange Online?
The endpoint stores the source server name, the authentication method, the trust relationship for the certificate, and the Outlook Anywhere transport path. Those settings must match the on-premises Exchange configuration at the moment you validate. If the source changes, update the endpoint only after the source is confirmed.
What are the requirements for an Exchange Online migration endpoint?
Outlook Anywhere must be enabled, and the certificate must be trusted and cover Outlook Anywhere and Autodiscover.
Can you update the migration endpoint with PowerShell?
Yes. Connect to Exchange Online PowerShell, run Get-MigrationEndpoint to inspect the current object, and then use the endpoint edit cmdlet available in your tenant to change the values that still match the source. Afterward, rerun validation and confirm the migration batch still points to the same endpoint.