EWS retirement: what breaks Oct 1, 2026, what breaks Apr 1, 2027

The Exchange Web Services shutdown is phased, tenant-by-tenant, and decided by two organisation-level settings. That means “everything breaks on October 1” is wrong, and so is “we have until 2027.” Which of the two applies to you is a thing you can read off your tenant in one command.

EWS: tenants that never opted in start getting disabled Oct 1, 2026 (includes Microsoft's own apps); allow-listed apps run until Mar 31, 2027; Apr 1, 2027 is final — no exceptions.

The timeline

Oct 1, 2026
Phased disablement begins, and enforcement starts in Exchange Online. “October 2026: EWS starts to be disabled globally for all organizations.”
Mar 31, 2027
The last day allow-listed applications work. Admins can re-enable EWS during this phased window.
Apr 1, 2027
“April 2027: EWS is fully disabled.” No extensions, no exceptions, no re-enablement.

Who breaks on Oct 1, 2026

Tenants that never opted in. EwsEnabled is tri-state, and a tenant that has never explicitly set $true has it changed to $false on October 1, 2026. Every EWS application in that tenant stops.
Tenants set to True with no allow list. From October 2026, setting EWSEnabled=True without configuring EWSAllowedAppIDs no longer permits unrestricted EWS access. Only allow-listed application IDs can call EWS. This one is softer than it looks: Microsoft pre-populates the allow list for customers who have not created one before September 2026, based on each tenant's own EWS usage telemetry, so read the list back from the tenant before assuming it is empty — and before assuming a pre-populated list caught the job that only runs monthly.
Microsoft's own applications, in those tenants. After the January 2024 Midnight Blizzard incident the scope was widened from third-party applications to include all Microsoft applications, and first-party applications that still rely on EWS have to appear in the allow list like anything else.

Not everyone breaks at once, and that is the whole shape of this. Disablement is phased, admins can re-enable during the phased window, and tenants with EWSEnabled=True plus a configured allow list will not have their EWSEnabled setting modified by Microsoft before April 2027.

Who breaks on Apr 1, 2027

Everyone still calling EWS, including every allow-listed application. This is the date with no mechanism behind it to argue with: EWS access is permanently removed, with no re-enablement, and Microsoft has confirmed there are no extensions or exceptions after it.

Read your tenant's posture or set the allow list.

What Microsoft Graph does not replace

Most EWS operations have a Graph equivalent, and the migration work is real but ordinary: different filter syntax, a different item schema, a different subscription lifecycle. A handful of operations have no equivalent at all. Those are the ones that turn a migration into a project, because no amount of code work moves them — they need a redesign, and the allow-list runway is the time you have to do it in.

DeadlineScan's mapping table covers 31 operations — 25 EWS, 6 QuickBooks Online. Twelve map cleanly, five map partially, nine are informational, and five are gaps, flagged inline in the report as [NO GRAPH EQUIVALENT — see runbook]. The four EWS gaps:

Public folders

There is no Graph equivalent for public folder access, and Microsoft has said the CRUD APIs for it will not be available. This is not a gap that closes later — it is a permanent boundary. The realistic path is to migrate the content itself to shared mailboxes, Microsoft 365 Groups, or SharePoint, using the allow-list runway to do it.

In-place (online) archive access

Graph's mailbox import/export API does reach archive mailboxes for bulk full-fidelity export, but that API is in preview and is not yet safe to build a production migration on. General in-place archive access — folder browsing and per-item operations equivalent to what EWS offers today — is still an open item on Microsoft's EWS-to-Graph parity roadmap with no committed date.

Microsoft 365 Group mailboxes

Graph's group conversation and group calendar APIs do not cover the same EWS group-mailbox surface, and Microsoft's roadmap explicitly excludes Microsoft 365 Groups from the in-progress mailbox import/export work. There is no direct mapping to hand you.

Mailbox import/export (`ExportItems` / `UploadItems`)

Graph does have a mailbox import/export API now, in preview, for standard, shared and archive mailboxes — but it explicitly excludes public folder and Microsoft 365 Group mailboxes, and it works in full-fidelity opaque streams rather than EWS's structured item access. Because a raw ExportItems call site does not reveal which mailbox type it targets, each one has to be triaged against the preview API's actual scope.

Microsoft's own published parity list also names sticky notes, event delta for recurring events, in-place archive redirects, and creating an event without sending invites.

And five that map only partially — three EWS, two QuickBooks

The mapping table's five Partial entries are the ones where the replacement exists but does not behave identically. Three are EWS:

Sync (SyncFolderItems). Graph delta queries are the equivalent change-tracking model, but delta tracking for recurring events is on Microsoft's own list of open parity gaps, so a sync loop's recurring-event path needs re-verifying rather than re-pointing.
Calendar. /events, /calendarView and getSchedule cover most of it; recurring series are the exception, for the same reason.
Delegates. Calendar-sharing permissions map to Graph's calendarPermission resource. Full mailbox delegate management — inbox, contacts and tasks delegation with EWS's finer-grained permission levels — is not represented the same way in Graph today.

The other two are on the QuickBooks Online side, where the endpoint survives but the payload changed underneath it:

Reports API, for a report that survived into v2. The endpoint keeps working; columns and rows were restructured, account hierarchies shifted, and blank cells now replace what used to be reported as zeros. What that looks like.
Webhook payload parsing. Deliveries and HMAC verification are unchanged; the payload is now a CloudEvents envelope, so a parser reading the legacy eventNotifications root fails silently. What that looks like.

Find your own call sites

DeadlineScan is a free, MIT-licensed command-line scanner. It walks a directory tree, reports every EWS and QuickBooks Online call site it recognises across C#, VB, PowerShell, Python, Java, JavaScript and dependency manifests, and marks the ones Graph does not replace. No compilation, no package restore, no network calls, no telemetry.

deadlinescan scan ./my-repo --json report.json

Get the scanner: email hello@deadlinescan.com and you'll get the source and a Windows binary by reply — the public repository is being prepared.

A finding count of zero means no affected call sites were FOUND — not that you're unaffected.

How it works, and what it does not do. If the gaps are yours, the Parity-Gap Runbook is the paid version of the plan described above.

Sources

Microsoft Learn — Deprecation of Exchange Web Services in Exchange Online: the October 2026 / April 2027 timeline, the widening of scope to all Microsoft applications, and the published parity gaps.
Microsoft Learn — Prepare for EWS retirement: the tri-state EwsEnabled setting and the April 1, 2027 hard deadline.
Microsoft Learn — Mailbox import and export in Microsoft Graph.
Microsoft Learn — Delta query overview and calendarPermission.
Message Center MC1447678 (archive copy) and MC1227454 (archive copy): enforcement from October 1, 2026, re-enablement during the phased period, and permanent removal after April 1, 2027.