EWS is off on Exchange Online and migration to Microsoft Graphh is urgent before April 2027

Microsoft has confirmed a news expected by many administrators and developers: the API Exchange Web Services (EWS) for Exchange Online will be completely deactivated in April 2027. After almost two decades acting as a bridge between Exchange applications and mailboxes, EWS will continue to be available at local Exchange Server facilities, but Microsoft 365-hosted mailboxes will need to stop using it before the deadline.

The road map Microsoft has proposed marks two key moments: from 1 October 2026 EWS will be blocked by default on Exchange Online, and on 1 April 2027 the final disconnection will occur without exception. Microsoft offers a management window to reduce impact: administrators can create lists of allowed applications and, if they do so before the end of August 2026, their organization will be excluded from that first automatic lock.

If an organization does not prepare its own list, Microsoft will start in September 2026 to generate pre-filled lists based on the actual use of each tenant, with the intention of minimizing unforeseen interruptions. In addition, to identify hidden dependencies, the company has announced that it could perform short-off controlled - which it has colloquially called "screen tests" - and will keep administrators informed by regular notifications at the Message Center with specific summaries and reminders per tenant. You can read the official ad and the Exchange team's explanations on Microsoft's technical blog: Exchange Team (Microsoft Tech Community).

To understand why Microsoft makes this decision it is appropriate to remember the role that EWS has played. Born with Exchange Server 2007, EWS made it possible to build customers and tools that read emails, manage calendars and contacts, and perform complex operations on mailboxes from different platforms. Over time, Microsoft has been promoting Microsoft Graphh as the modern API that integrates identities, mail, calendars, files and many other functions under a single model with security and scalability improvements. The warning process is not new: already in 2018 Microsoft advanced changes and, in 2021, disable a subset of the less used calls for security reasons; you can consult those notices at the TechCommunity: 2018 notice and the 2021 communication.

What does this mean for companies and developers? First, any application that still uses EWS to access cloud mailboxes should plan a migration. Microsoft recommends switching to Microsoft Graphh, which already offers feature parity for most scenarios and includes authentication improvements and access control. The company publishes guides to help with migration and the adaptation of calls and permits: Migrate applications from EWS to Microsoft Graphh.

Second, administrators should audit and map the use of EWS in their environment: identify applications, scripts and services that make EWS calls, prioritize the most critical and coordinate tests. Microsoft has provided permit listing mechanisms to give time to transition, but these mechanisms are temporary. In addition, the company will provide automatic information on the use of EWS by tenant to help detect hidden dependencies before the mass block.

There is an important note for hybrid environments: the withdrawal affects Exchange Online (the cloud). The on-prem facilities will continue to support EWS, but interactions between hybrid scenarios and the cloud may require specific components for Microsoft Graphh calls to work properly. Microsoft has explained that Autodiscover will continue to be the way to determine where a mailbox is, and that hybrid customers will need to have the necessary infrastructure to support Graph when they call cloud mailboxes; it is appropriate to review the manufacturer's technical documentation for specific details of each topology.

Practically, what should you do now? The recipe is simple in your idea: inventory, testing and migration. Make a comprehensive inventory of customers and scripts using EWS, prioritize critical cases and start rewriting or adapting those integrations to Microsoft Graphh. Use the official tools and guides to minimize reworks, and plan test windows before the October 2026 block. Microsoft offers resources and documentation for developers on the Microsoft Graphh page; it is a good starting point for understanding permissions, endpoints and authentication flows: Microsoft Graphdocumentation.

It is not appropriate to rely on the mechanism of lists allowed as a long-term solution: they are a temporary relief, not a permanent alternative. The risk is to discover late hidden dependencies - for example, internal integrations or third-party applications that no one actively maintains - and that these services will be out of service by an unexpected blockade. That's why Microsoft proposes controlled tests and monthly notifications so that organizations can react in time.

Finally, although this transition is technical, it is still an opportunity: migrating to Graph usually brings benefits in security (more fine permit management, support for modern OAuth standards), maintenance (a single API for many services) and functional possibilities (more direct integration with Teams, OneDrive and other Microsoft 365 services). If your organization still depends on EWS on Exchange Online, it is appropriate to treat the Microsoft calendar as a real deadline and activate resources for migration in advance.

For more details and the official picture, check the Exchange team's entry into Microsoft's TechCommunity and the Microsoft Graphh migration guide:

Exchange Team announcement and EWS to Microsoft Graphh Migration Guide.

In summary: EWS for Exchange Online has cloud expiry date: it prepares inventory, prioritizes migration and uses the management window Microsoft offers to avoid impacts when October 2026 and, definitely, April 2027.