Introduction

An Exchange migration can complete for end users while a CRM, ticketing tool, calendar sync app, or mailbox integration still talks to the old Exchange Web Services endpoint. Mailboxes may already live in Microsoft 365 or on a new Exchange environment, but the application keeps using a hardcoded EWS URL, an old service account profile, or a cached discovery result that survived the move.

Treat this as an integration-endpoint problem instead of an Outlook problem. Start by identifying the exact EWS URL the application is calling, because many server-side integrations do not follow the same Autodiscover path as desktop clients and can stay pinned to the legacy Exchange server long after user devices are fixed.

Symptoms

  • An integration that reads calendars, mailboxes, or contacts still tries to reach the old Exchange server
  • The app shows certificate or authentication errors that reference the retired Exchange hostname
  • User Outlook clients work after migration, but the connected business app still fails
  • The integration can authenticate, but mailbox sync, availability, or calendar actions stop working
  • Logs from the app or middleware still show the previous EWS URL
  • The issue started after Exchange cutover, hybrid cleanup, or moving mailboxes to Microsoft 365

Common Causes

  • The application stores a hardcoded EWS endpoint that was never updated
  • A service account or integration profile still references the old Exchange server name
  • The app caches Autodiscover or endpoint discovery results and never refreshed them after migration
  • Load balancer, reverse proxy, or DNS changes moved users successfully but not the app integration path
  • The migrated environment requires a different authentication method, but the app keeps trying the old one against the old endpoint
  • Migration validation focused on user clients instead of mailbox-connected applications and services

Step-by-Step Fix

  1. Check the application or integration logs and identify the exact EWS URL, hostname, and authentication path it is using, because you need the real endpoint in use rather than the endpoint you assume the app should follow.
  2. Compare that live EWS target with the intended post-migration Exchange or Microsoft 365 endpoint, because many apps keep a manually entered URL that does not change when user mailboxes move.
  3. Review the integration settings for saved service-account profiles, mailbox connection objects, or tenant-specific connection records, because server-side apps often store Exchange connection details separately from normal user mail settings.
  4. Verify whether the application relies on Autodiscover or on a fixed EWS URL, because an integration that bypasses discovery will never follow DNS or profile changes made for Outlook users.
  5. Check whether cached tokens, discovery data, or middleware configuration still preserve the old endpoint, because some apps continue retrying the retired server even after you change the visible configuration field.
  6. Confirm that the destination environment supports the authentication method the app now needs, because modern Exchange environments may require a different auth flow and that mismatch can keep teams chasing the wrong server problem.
  7. Update the active integration endpoint only after confirming the correct EWS URL and mailbox access model, because changing one visible field without the related auth settings often leaves the integration broken in a new way.
  8. Run a controlled mailbox or calendar sync test and verify in logs that the app now reaches the intended endpoint, because a successful login screen or saved configuration does not prove the old Exchange server is no longer being called.
  9. Document every mailbox-connected application that uses EWS and its final endpoint after the migration, because server-side Exchange integrations are commonly missed during cutover validation.