Legacy Exchange access is rarely one feature. It is a collection of Outlook transports, virtual-directory authentication methods, mobile protocols and application APIs that may have different support and retirement paths.

The safe sequence is discover, own, replace, observe, enforce and remove.

Separate the environments

Begin by marking every dependency as:

  • Exchange Online;
  • on-premises Exchange Server;
  • hybrid/coexistence; or
  • a third-party service that happens to access Exchange.

Exchange Online Basic authentication retirement, Exchange Online EWS deprecation and on-premises virtual-directory authentication are not one event. Do not apply a cloud announcement mechanically to an on-premises service—or use on-premises support as a reason to ignore a cloud deadline.

Inventory clients and applications

Use server logs, Microsoft 365 sign-in/service evidence, load balancer/proxy logs, application inventories and owner interviews to find:

  • Outlook versions using MAPI over HTTP or Outlook Anywhere;
  • ActiveSync/mobile clients;
  • POP/IMAP clients;
  • EWS applications and service accounts;
  • scanners and line-of-business SMTP senders;
  • Remote PowerShell/administration tooling;
  • migration, backup, archive, signature and security products; and
  • scripts that store usernames/passwords.

Record volume and last-seen over a period long enough to catch monthly or failure-only jobs. “No activity today” is not retirement evidence.

Prefer MAPI over HTTP for supported Outlook

MAPI over HTTP is Microsoft’s modern Outlook transport for supported Exchange Server/Outlook combinations. Outlook Anywhere, also called RPC over HTTP, is legacy and does not support OAuth in Microsoft’s current on-premises matrix.

Before retiring Outlook Anywhere:

  • confirm server versions/updates support the target;
  • confirm Outlook clients are supported and current;
  • verify MAPI over HTTP organisation and mailbox state;
  • validate namespaces, certificates and proxies;
  • observe client protocol use; and
  • resolve applications that depend on another path.

Do not disable Outlook Anywhere merely because MAPI/HTTP is enabled; Microsoft notes that capable and incapable clients can coexist depending on configuration.

Treat authentication and protocol separately

A protocol can support more than one authentication method. Modern Authentication availability depends on Exchange version, current updates, identity topology and protocol.

Map each pair explicitly:

Workload Current protocol Current auth Target Owner
Desktop Outlook RPC/HTTP NTLM/Basic path Supported MAPI/HTTP design End-user computing
Mobile mail ActiveSync Legacy auth Supported OAuth client Mobility
Calendar integration EWS App credential Graph or supported exception plan Application owner

Do not describe “modern auth enabled” as proof that every client uses it.

Handle EWS as an application portfolio

Microsoft has announced an Exchange Online EWS retirement path. Inventory every application using EWS and the operations it performs: mail, calendar, contacts, impersonation, subscriptions or migration.

Assess Microsoft Graph or another supported API per function. Microsoft acknowledges some parity gaps; a migration plan should record them rather than promise a blind endpoint swap.

For each application, define:

  • business outcome and data accessed;
  • delegated or application permission;
  • mailbox scope;
  • supported replacement and vendor version;
  • functional and throttling tests;
  • event/subscription behaviour;
  • audit and incident visibility; and
  • old credential/API removal.

Do not reuse a broad EWS service account as a broad Graph application.

Replace password-based service access

Human attended administration should use current interactive authentication. Unattended workloads should use a workload identity with supported certificate or managed-identity authentication and least privilege.

For POP/IMAP/SMTP workflows, determine whether OAuth on the existing protocol is sufficient or whether Graph, connector relay or a purpose-built service is better. Do not preserve Basic authentication because an old device lacks updates; give the device a supported relay, replacement or retirement decision.

Enforce in controlled scope

Use the narrowest supported policy, mailbox, virtual-directory or client scope. Before enforcement:

  • export the current configuration;
  • name the rollback command/change;
  • notify affected owners;
  • define a short observation window;
  • monitor authentication and client protocol evidence; and
  • provide an approved fallback that does not become permanent.

Do not change every virtual directory and external entry point at once unless the tested architecture requires a coordinated cutover.

Verify negative and positive outcomes

After the change, prove:

  1. the supported client/application completes its full workflow;
  2. the legacy protocol or authentication attempt is rejected;
  3. unrelated Exchange access still works;
  4. internal and external paths behave consistently;
  5. monitoring detects legacy retries; and
  6. rollback works within the stated window.

A lack of helpdesk calls is weak evidence. Some automated jobs fail silently until their next scheduled run.

Remove the residue

When the observation window is complete, remove:

  • obsolete credentials and app passwords;
  • unused application registrations or certificate grants;
  • legacy policy exceptions;
  • unsupported clients and server settings;
  • stale DNS/proxy paths where their owning service is gone; and
  • documentation that instructs staff to re-enable the old route.

Keep a small exception register for dependencies that cannot yet move, with owner, evidence, compensating controls, deadline and current vendor position.

Legacy client access is retired only when the old attempt is proven blocked and every real business workflow has a supported, observed replacement.