EWS Retirement in Exchange Online: What Business System Owners Should Check

If a business application depends on Exchange Web Services (EWS) in Exchange Online, identify the functions it uses and confirm how those functions will continue before approving a rebuild. A supported supplier update or integration change may cover the requirement. Replacing the whole application becomes a question when the available route cannot support the work your business needs.

For the person approving the budget, the useful starting point is a short dependency record: what the connection does, who owns it, which supported route will replace it, and what evidence will demonstrate that the business function works.

Understand the current timeline and scope

Microsoft's general EWS retirement notice describes two stages. Phased, administrator-controllable disablement began on October 1, 2026, tenant by tenant. Access during this transition depends on tenant settings and application controls, so the date alone does not establish whether your connection is currently blocked. Permanent shutdown begins on April 1, 2027, when administrators lose the ability to control EWS access through the tenant setting.

That notice applies to Microsoft 365 and Exchange Online. It leaves EWS in on-premises Exchange Server outside this retirement. Ask the technical owner to confirm which environment the affected connection actually reaches.

Temporary restoration of EWS access can provide transition time where permitted. Give any such measure an owner and a completion date for the replacement route. Restored access demonstrates that the existing connection can run again; it provides no evidence that the application is ready for permanent shutdown.

Connect the technical dependency to an operational owner

Begin with the people responsible for the connected systems. Ask IT for EWS usage evidence and ask each application owner what the identified connection does. Microsoft's deprecation guidance points administrators to usage reports and analysis tools.

An application identifier becomes useful to a budget owner when it can be tied to a business function. For example, a connection might update appointments in a scheduling system. The consequence of failure could be staff working from an outdated schedule. That consequence helps determine priority and who must approve the result.

Record these details for each dependency:

• Function and consequence: what the connection does, how often it matters, and what happens if it fails.
• Application and accountability: the system, supplier, and internal person responsible for its continued operation.
• Technical requirement: the EWS operations or capabilities used, plus the mailbox and environment involved.
• Continuation evidence: the proposed supported destination, the supplier release or documentation covering it, and any remaining gap.
• Delivery and acceptance: who will make the change, by when, and which business check must pass.

A report of observed activity helps locate a dependency. The application owner still needs to explain its operational importance, including occasional work such as month-end processing.

Check the capability behind the proposed replacement

Microsoft Graph supports many EWS scenarios, but complete equivalence should not be assumed. Microsoft's capability roadmap identifies remaining gaps, alternatives, and capabilities that will not be added. For example, public-folder import and export is separate from routine create, read, update, and delete access. A proposed route must cover the operations your application needs.

The same roadmap says estimated availability dates are targets that may change. A quarter appearing in a roadmap, even one that has already passed, is insufficient evidence of delivery. Ask the supplier or technical owner to identify the available capability and the release that uses it.

If a supported application update covers the required functions, assess its cost, deployment needs, and acceptance evidence. If an integration change can cover them, assess that scope. Where a required component has no suitable supported route, compare another component, a changed workflow, or another application. Keep the comparison tied to the missing function and its business consequence so that the decision has a clear basis.

Approve a result you can verify

For an illustrative scheduling check, create an appointment through the connected system, change its time, and confirm the expected records update for the intended users. Check that permissions still fit their roles. Include a failed action and confirm that a responsible person can see and resolve it. Agree the expected results before testing.

A successful sign-in proves one part of the connection. Acceptance should demonstrate the actual work, including a consequential failure case. Attach the result to the dependency record so the owner approving completion can see what was checked.

If you need help with an affected business-system connection, describe the application and the function it performs. We offer API integration services; that context provides a starting point for discussing the scope of the required work.