EWS Ends in Exchange Online on 1 April 2027: Moving Your Integrations to Microsoft Graph

Microsoft has started switching off Exchange Web Services (EWS) in Exchange Online. The first enforcement steps run this month, tenants that never touched their EWS settings get switched off one by one after that, and from 1 April 2027 EWS is gone for every Microsoft 365 tenant. Microsoft has said plainly that there will be no exceptions past April 2027.

If something your company built talks to Microsoft 365 mailboxes over EWS, it stops working by that date at the latest, and possibly much sooner. The usual suspects: a CRM that files customer emails against accounts, an archiving or retention script, a meeting room booking screen, a ticketing system that reads a shared support mailbox, a reporting job that counts emails per team. The fix is a rewrite against Microsoft Graph, and some of what EWS could do has no Graph equivalent at all.

What Happens, Date by Date

Microsoft controls EWS per tenant through the EWSEnabled setting, which has three values: Null (the default), True and False. Next to it there is now a second setting, EWSAllowedAppIDs: a list of application IDs that may still use EWS. The current Microsoft Learn page gives the outline: "October 2026: EWS starts to be disabled globally for all organizations" and "April 2027: EWS is fully disabled."

The detail is in the Exchange Team's post of 1 October, EWS Deprecation Is Here. For the worldwide commercial cloud:

• 2 October 2026, end of day Pacific Time: Microsoft records every tenant that has EWSEnabled set to True but no allow list.
• 8 and 9 October 2026: for those tenants, Microsoft creates the allow list and fills it with the application IDs that used EWS in the previous 60 days.
• From 10 October 2026: when EWSEnabled is True, the allow list is required. An app that is not on it is refused.
• Second phase, after that: tenants still at Null get EWSEnabled set to False, which blocks EWS for every application. Each gets a 7-day warning in Message Center, and Microsoft fills an allow list from 60 days of usage shortly before, so an admin can switch EWS back on with True.
• 1 April 2027: EWS is "fully and permanently disabled", and tenant admins lose the ability to change EWSEnabled at all.

Tenants in Microsoft's other clouds get their own timelines through Message Center.

The allow list buys time, not a solution

The automatic list is built from 60 days of traffic, and Microsoft's own guidance of 4 September warns that it "may miss applications that run infrequently". A quarter-end export or a year-end archive job will not be on it, and will fail the next time it runs.

Changes to the allow list take 24 hours to take effect, and changes to EWSEnabled take about an hour. Any fix you make after a failure costs at least a day.

To see where your tenant stands, an admin with Exchange Online PowerShell can run:

Get-OrganizationConfig | Format-List EWSEnabled
Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsAllowedAppIDs

Who This Is For, and Who Can Stop Reading

On-premises Exchange Server is not affected. Microsoft says the retirement applies "only to Microsoft 365 and Exchange Online", and that "there are no changes to EWS in Exchange Server". If all your mailboxes live on your own servers, you can stop here.

Hybrid setups need a closer look. Mailboxes on premises can keep using EWS; mailboxes in the cloud must move to Graph. Microsoft's hybrid post of 30 September covers two cases that need action now, including on-premises mailboxes with archives in Exchange Online, where the advice for the moment is to keep EWS enabled and put the hybrid application on the allow list.

Packaged software is the vendor's job. If the thing calling EWS is a commercial product, shipping a Graph version is the vendor's job, and yours is to get a date from them and install the update. Microsoft's own clients are no different: some still appear in usage reports and need the allow list until updated.

In-house code is your job. Scripts, internal services, customised open source tools and integrations an agency built years ago have nobody upstream to fix them. That is where the work is. For scale: exchangelib, a Python library for talking to Exchange over EWS, was downloaded 1,174,625 times from PyPI in the past month. Some of that is on-premises use, but it gives a sense of how much code speaks EWS directly.

Step One: Find Everything That Uses EWS

Start with the EWS usage report in the Microsoft 365 admin center (Reports, Usage, Exchange, then the EWS usage tab). For each application it lists the Microsoft Entra application ID, every SOAP action that application called, the call volume and the last activity date. You can look back 7, 30 or 90 days and export to CSV.

Three things to know about it:

• Data is aggregated weekly and can take up to 10 days to appear.
• An application ID is not an owner. Match each ID against Enterprise applications in Microsoft Entra, then find the person or team who runs it. Expect a few IDs nobody recognises.
• The SOAP action column tells you how big each job is. An app that only calls FindItem and GetItem is a short job. One that calls SyncFolderItems, Subscribe and ExportItems is a project.

Even 90 days misses annual jobs, so check the other side too: scheduled tasks and cron entries, and code repositories searched for the EWS endpoint (Exchange.asmx), the EWS Managed API for .NET, and exchangelib. Microsoft's deprecation page also links an EWS analyzer for .NET code (it flags EWS calls in Visual Studio and VS Code and suggests Graph equivalents) and a tutorial on AI-assisted refactoring.

Step Two: Decide What Each Integration Becomes

Every application on the list gets one of four answers:

1. Retire it. Some integrations exist only because nobody turned them off.
2. Update it. Vendor products get a vendor upgrade. Agree the date now.
3. Rewrite it against Microsoft Graph. The default for in-house code.
4. Redesign it. For anything that relies on a capability Graph will never have (see below).

Microsoft also lists Power Platform as a way to reimplement a workflow. For a script that forwards attachments to a folder, that can be the cheapest answer.

What a Graph Rewrite Actually Involves

Most EWS operations have a direct Graph counterpart, and Microsoft maintains an EWS to Graph mapping. The mapping is the easy part. The harder parts are the ones it does not show.

Permissions get narrower, and that is a feature

An app that uses EWS without a signed-in user holds the EWS application permission, which Microsoft describes as "full access to all mailboxes". Graph splits that into separate permissions: Mail.Read, Mail.ReadBasic, Mail.Send, Calendars.ReadWrite, MailboxSettings.Read and so on.

You can also limit which mailboxes an app reaches. RBAC for Applications in Exchange Online assigns a permission against a management scope or an administrative unit, and it replaces the older Application Access Policies. A room booking screen can read the calendars of twelve room mailboxes and nothing else. One trap: grants made this way are added to any tenant-wide grant in Microsoft Entra, so if Mail.Read is still consented there, your scope restricts nothing. Remove the Entra grant.

Use certificates rather than client secrets for app authentication where you can, and keep credentials out of scripts and repositories.

Sync and notifications are rebuilt, not translated

This is usually the biggest change for anything that keeps a local copy of mailbox data.

Sync. SyncFolderItems maps to the Graph messages delta query, and SyncFolderHierarchy to the mail folder delta query. Message delta works one folder at a time, so a full mailbox sync means tracking the folder tree and storing a separate delta link per folder. Filtering is limited (only on received date), and the results include deletions, moves out of the folder and read state changes even when they do not match your filter.

Notifications. EWS streaming and push subscriptions become Graph change notifications, delivered to a webhook you run or to Azure Event Hubs or Event Grid. A webhook has to be reachable from Microsoft's side, which is an architecture change for a script that used to hold a connection open from behind the firewall. Subscriptions for mail, calendar and contacts last at most 10,080 minutes (just under seven days), or 1,440 minutes when the notification carries the data, so something has to renew them. Each mailbox allows at most 1,000 active subscriptions across all applications.

The pattern that holds up: treat a notification as a hint, run the delta query to see what changed, and run it on a timer as well to catch anything a missed notification would have lost.

Data, IDs and throughput

• Stored IDs. If your CRM or ticketing system saved EWS item IDs to link emails to records, those links need converting. Graph has a translateExchangeIds function for exactly this. Plan the conversion as a migration step of its own.
• Lookups. ResolveNames maps to the People API, GetUserAvailability to getSchedule, out-of-office settings to mailbox settings. Close equivalents, not identical ones.
• Throttling. Graph limits each app and mailbox pair to 10,000 requests per 10 minutes, four concurrent requests, and 150 MB of uploads per 5 minutes. A bulk job that ran dozens of parallel EWS threads against one mailbox has to be redesigned around those numbers.

The gaps, and what will never come

Microsoft publishes a roadmap of EWS capabilities still missing from Graph. It includes full-fidelity import and export for archive, public folder and group mailboxes, access to in-place archives, folder permissions through the Exchange Admin API, and creating non-draft messages from MIME. Most targets are the fourth quarter of 2026. A few were due in the third quarter, which has now ended, so check what has actually shipped before you design around it. Microsoft's own warning: if a capability is not on the roadmap, "don't plan on" a Graph equivalent before EWS is switched off.

Three capabilities are confirmed as never coming to Graph:

• Generic public folder access (create, read, update, delete of folders and items).
• Generic Microsoft 365 Group mailbox access. Graph covers group conversations, threads and posts instead.
• Discovery mailbox access. Microsoft points to Purview eDiscovery instead.

If a tool depends on one of these, porting the code is not enough: the data or the workflow has to move somewhere else first, and that takes longer than a rewrite.

A Six-Month Plan

From today to 1 April 2027 is just under six months. A realistic order:

October 2026: see where you stand. Check EWSEnabled and the allow list. Export 90 days of the usage report. Review the list Microsoft filled in, remove what should not be there, and add the infrequent jobs you know about. If your tenant is still at Null, consider setting the list and True yourself rather than waiting for Microsoft's switch to False and finding out what breaks.

November 2026: triage. Assign an owner and an answer (retire, update, rewrite, redesign) to every application ID. Scan the code. Flag anything touching public folders, group mailboxes or discovery mailboxes and start the redesign now. Create the Graph app registrations with scoped permissions.

December 2026 to January 2027: build. Start with the integration the business would miss first. Build the sync and notification plumbing once and reuse it. Convert stored IDs.

February 2027: run both side by side. While EWS still works, run old and new versions against the same mailboxes and compare the output. As each one is accepted, take its ID off the allow list. That is also the test: wait the 24 hours and confirm nothing else stopped.

March 2027: switch EWS off yourself. Set EWSEnabled to False well before 1 April. Anything you missed fails while you can still switch EWS back on. After 1 April that option is gone. Give quarterly and annual jobs a deliberate test run before then too: a job that runs when the first quarter closes will run for the first time after EWS is gone.

Where to Get Help

The hard case is the integration whose original developer has gone. Our legacy system maintenance service is built for that: we read the existing code, rewrite the EWS parts against Microsoft Graph (permissions, sync, notifications, ID migration) and run old and new side by side until the numbers match. If you need engineers to work inside your own team instead, see our staff augmentation service.

If your usage report is full of application IDs nobody recognises, write to office@c9group.dev.