Worth Knowing
What is changing
Exchange Web Services, commonly called EWS, is an interface applications have used to work with Exchange Online data.
Microsoft has been moving away from EWS for years. Microsoft stopped adding functionality updates to EWS in 2018 and announced in 2023 that EWS would be disabled in Exchange Online beginning in October 2026. Microsoft’s current guidance describes a phased disablement beginning October 1, 2026. [learn.microsoft.com]
For many organizations, the useful question is not simply“What is EWS?”
It is:
“Which business tools still depend on it?”
Verified context
Microsoft is directing organizations toward Microsoft Graph where the required capabilities are supported. Microsoft also notes that some EWS-to-Graph capability gaps remain and is publishing guidance and tools intended to help organizations identify EWS applications and plan migrations. [learn.microsoft.com]
EWS has been used broadly for years, so discovering an EWS dependency is not evidence by itself that something was implemented poorly.
The important questions are whether the dependency is still active, whether it has an owner, whether a supported replacement path exists, and whether the underlying business workflow is still necessary.
Begin with an inventory, not an immediate replacement project.
Why it matters
An application can become business-critical without leaving behind a clear record of who owns it.
A calendar integration may control appointments.
An archive may support an important records process.
A migration utility may be used infrequently but become essential during a particular project.
A custom application may have a narrow set of maintainers, an old vendor relationship, or unclear current ownership.
The visible Exchange environment may not reveal every application that quietly depends on Exchange.
EWS retirement is therefore a business-dependency and vendor-management issue as much as it is a technical Exchange issue.
Who should care
Technology leaders, Microsoft 365 administrators, application owners, records and compliance leads, finance and operations teams, and relevant third-party vendors may all have a role.
Organizations that have accumulated specialized applications over time should pay particular attention to ownership.
The people using a workflow every day may have no reason to know whether EWS is part of the workflow’s technical foundation.
Areas to review
Third-party software
Line-of-business systems
Archive platforms
Mailbox tools
Scheduling and calendar integrations
Migration products
Service principals associated with applications
Custom integrations
The purpose of the review is not simply to count integrations. It is to connect each relevant dependency to an owner, a business process, and a supported direction.
Questions worth asking
Is EWS currently used?
Which product or workflow is using it?
Who owns the application and the vendor relationship?
What business process is affected if the application stops working?
Is an appropriate Microsoft Graph path available for the required capability?
Does the vendor support that path in the exact product and version the organization uses?
Would replacing the integration make sense, or is retiring the dependency more appropriate?
A vendor’s general statement that it “supports Graph” is less useful than understanding the supported path for the organization's particular product and workflow.
The dependency needs an owner before it needs a migration plan.
A practical high-level path forward
A responsible planning sequence can begin with an application and ownership inventory.
Identify relevant applications and integrations. Establish where EWS is actually being used rather than assuming every Exchange-connected application depends on it.
Establish ownership. Connect each important dependency to a responsible business or technical owner and, where applicable, a vendor relationship.
Understand business impact. Determine what workflow is affected if the dependency stops working.
Confirm the supported direction. For important dependencies, obtain current vendor or technical guidance for the exact product, version, and required capability.
Prioritize by impact. A long list of low-impact dependencies should not automatically receive more attention than one critical workflow.
Test the supported replacement. Validate the intended replacement with the actual business process it supports before retiring a working dependency.
Document the decision. Record whether the organization will migrate, replace, redesign, retire, or otherwise address the dependency.
Do not turn discovery into rushed programming work before the business dependency and supported direction are understood.
The objective is not to replace EWS everywhere at any cost. The objective is to prevent an unknown dependency from becoming an avoidable business interruption.
Key Takeaways
EWS can be embedded in products users do not recognize as Exchange dependencies.
Microsoft is retiring EWS in Exchange Online and directing organizations toward Microsoft Graph where the necessary capabilities are supported. [learn.microsoft.com]
Inventory and ownership come first. An organization needs to know what depends on EWS, why it matters, and who is responsible for it.
Vendor roadmaps should be confirmed for the exact product and workflow. General statements about Graph support do not answer every migration question.
Test a supported replacement before retiring a working dependency. The business process matters as much as the technical interface.
