Exchange Online EWS retirement: an October 2026 readiness plan
A practical readiness plan for discovering EWS dependencies, controlling temporary access and moving Exchange Online integrations forward.
Executive summary
Microsoft’s phased disablement of Exchange Web Services in Exchange Online begins in October 2026, with complete shutdown planned for 2027. The change applies to Exchange Online, not Exchange Server on-premises.
Organisations should identify applications using EWS, decide which can be retired, plan Microsoft Graph migrations and use the temporary App ID allow-list controls only where a documented dependency remains. An allow list is a transition control, not a replacement for migration.
Why it matters
EWS dependencies are often hidden inside calendar integrations, migration products, service-desk tools, room-booking systems, archives and custom applications. Application owners may know the product but not the protocol it uses. Waiting for a failure turns protocol discovery into incident response.
Hybrid organisations need to distinguish mailbox location and call path. Microsoft states that on-premises EWS is not being retired by this Exchange Online change, while access to cloud mailboxes must follow the Exchange Online plan.
A practical discovery sequence
Start with evidence
Review the EWS usage reporting available in the Microsoft 365 admin experience and the discovery guidance published by the Exchange team. Reconcile observed App IDs with enterprise applications, app registrations, vendor products and named business owners.
For each dependency, record the mailbox population, operations performed, authentication model, data handled, business criticality and vendor migration position. “The app still works” is not a retirement plan.
Classify every application
Use four outcomes:
- Retire — the application or feature is no longer required.
- Replace — move to a supported product or native capability.
- Migrate — redesign the integration for Microsoft Graph or another supported interface.
- Temporarily allow — keep a justified EWS dependency operating during a controlled transition.
Assign an owner and target date to every item. Unknown ownership should be treated as a risk, not as permission to keep the dependency.
Understand the October control change
Microsoft describes a change in how the tenant-level EWSEnabled state and the App ID allow list operate during phased disablement. Tenants that need temporary EWS access should follow the current Exchange-team guidance for EWSAllowedAppIDs and the applicable EWSEnabled state.
Do not copy a PowerShell command from an old article without checking the current documentation. The final value depends on whether the intention is to block EWS, permit only approved applications or temporarily restore broader access during transition.
Keep any exception narrow. Validate the App ID, application owner and required operation. Record expiry, monitoring and rollback. Revisit the list after every migration wave.
Migration and validation
Map EWS operations to supported Microsoft Graph capabilities. Confirm permissions, throttling behaviour, webhook or polling design, mailbox coverage and error handling. Redesign consent rather than carrying broad legacy access into the replacement.
Test with representative mailboxes and business workflows. Validate authentication, calendar or message behaviour, audit evidence and failure handling. Run the EWS usage report again after cutover to confirm that the old protocol traffic has stopped before removing the exception.
Risks and limitations
Product vendors may have their own timelines and supported migration paths. Microsoft Graph does not make every EWS implementation a mechanical one-to-one conversion. Cross-tenant calendar sharing and hybrid scenarios need their own review.
This article is operational guidance, not a tenant-specific command sequence. Dates and transition controls can change; confirm the current Exchange-team announcement before implementation.
Tested versions
No tenant commands are presented. The dates and control model were checked against Microsoft Exchange documentation on 19 September 2026.
Community discussion
Questions and comments
Share a question, correction or implementation experience. Comments are public and require a GitHub account. Please do not include tenant names, credentials, logs or other confidential information.