Exchange Web Services ends in Exchange Online: what you need to do before 1 October 2026

Exchange Web Services — EWS — is the XML-based API that applications have been using for almost twenty years to communicate with Exchange mailboxes. Email clients, backup software, CRM integrations, calendar synchronisation tools, and countless internal scripts rely on it. And that changes abruptly on 1 October 2026.

On that date, Microsoft begins phasing out EWS in Exchange Online. The API disappears entirely on 1 April 2027. For IT teams that haven't heard of this deadline, the next six weeks are the last opportunity to act. Microsoft updated its guidance on 13 August 2026 and introduced a new management tool that gives organisations some additional room — but no extension.

What is Exchange Web Services and why is it being retired?

EWS was introduced in 2007 as the standard API for accessing Exchange mailboxes, calendars, contacts, and tasks from external applications. It operates via SOAP messages over HTTPS, a technique that was common in 2007 but is now considered outdated. In 2018, Microsoft announced that no new features would be added to EWS. The modern successor, the Microsoft Graph API, has since been the recommended way to communicate with Exchange Online.

Graph API provides the same functionality as EWS, but on a modern REST/JSON basis that better matches how applications are built today. It is also the only API that provides access to the broader Microsoft 365 services — Teams, SharePoint, OneDrive, and Intune — from a single unified entry point.

One important detail: the EWS retirement applies exclusively to Exchange Online in Microsoft 365. Exchange Server on-premises is not affected and retains EWS support. Organisations with a hybrid environment must therefore carefully identify which mailboxes fall under the deadline.

The exact timeline you need to know

Three dates are critical. First, 1 October 2026: Microsoft begins disabling EWS by default in Exchange Online tenants. Apps still using EWS without approval via EWSAllowedAppIDs will no longer have access. Second, 1 April 2027: EWS is fully decommissioned in Exchange Online. No workaround will be possible at that point, not even via the allowlist.

Now — before 1 October 2026 — is the window to configure EWSAllowedAppIDs as a bridge, map your dependencies, and plan migrations. Anyone who waits until October risks immediate outage of business applications.

EWSAllowedAppIDs: the new transition setting

Microsoft introduced the EWSAllowedAppIDs setting in mid-2026 as a managed transition mechanism. Before this setting, the general rule was: if EWSEnabled was set to True, all applications had access. That changes from 1 October. Only applications whose App ID is explicitly on the approved list will retain access after that date.

EWSAllowedAppIDs is a tenant-level setting configured via Exchange Online PowerShell. You specify a list of Application IDs — the unique identifiers of apps in your Azure AD or Entra ID — that are allowed to continue using EWS. Apps not on the list will be rejected from 1 October onwards, even if EWSEnabled is still set to True.

This setting is a temporary measure, not a permanent solution. From 1 April 2027, this option also expires. The only definitive solution is migration to Microsoft Graph.

Which applications might still be using EWS?

The category of apps using EWS is broader than most IT teams realise. Five categories are most at risk. First, backup software: virtually all Exchange and mailbox backup vendors use EWS for mailbox access. Check with your vendor whether their current version is Graph-compatible and what the migration path looks like. Second, CRM systems: many CRM integrations that synchronise email and calendar with Exchange Online use EWS as the integration mechanism.

Third, migration and archiving software: tools used for email migration projects, as well as legacy archiving solutions, often still operate on EWS. Fourth, third-party email clients: while most modern clients already use Graph or IMAP, there are still specialist clients for specific sectors that rely on EWS. Fifth, internal scripts and automations: any PowerShell module, Python script, or internal application that reads or writes mailbox data via EWS will fail after 1 October.

How to inventory your EWS usage

Three steps to map your dependencies. Step one: consult the Microsoft 365 Message Center. Microsoft sends tenant administrators targeted messages when EWS activity is detected in your tenant. If you have received such messages, you already know that action is required and which apps have been seen.

Step two: use Exchange Online PowerShell to retrieve diagnostic information. The Get-EWSApplicationAccessPolicy cmdlet and related logging commands let you see which App IDs have recently made EWS requests. Compare that list against your known applications.

Step three: proactively ask your vendors. Make a list of all third-party software that communicates with Exchange Online and ask each vendor explicitly whether their product uses EWS and whether a Graph-compatible version is available. Get the confirmation in writing.

Migrating to Microsoft Graph: what it means in practice

For organisations with internally developed scripts or applications, migration to the Graph API is the only sustainable solution. Graph provides all the functionality that EWS delivered — reading and writing email, calendar, contacts, and tasks. The API operates on OAuth 2.0 tokens via Entra ID and offers more granular permissions than EWS ever did.

Microsoft has published comprehensive migration documentation with an overview of which EWS methods correspond to which Graph endpoints. For most common EWS operations, the transition is a matter of months, not years. The biggest effort lies in the inventory and testing, not in the technical implementation itself.

For third-party applications, the dependency is different: you rely on your vendor's roadmap. If no Graph-compatible version is available for your current software version, this is also the moment to ask whether the tool still fits your environment.

What if you cannot meet the 1 October deadline?

Configuring EWSAllowedAppIDs before 1 October for applications that have not yet migrated buys time until 1 April 2027. That is the realistic approach for organisations with complex dependencies. The priority is then: configure EWSAllowedAppIDs for critical apps, and run the Graph migration in parallel for those apps.

Doing nothing at all risks immediate outage on 1 October for every application using EWS. That can mean: no mailbox backup, no CRM synchronisation, no calendar integration, and failing scripts. In business-critical environments, that is an incident that is entirely avoidable.

Want help inventorying your EWS dependencies, configuring EWSAllowedAppIDs as a bridge, or migrating internal scripts to Microsoft Graph? Contact Zarioh — we know your Microsoft 365 environment and guide the process from inventory to completion.