I keep a running list of things that quietly stopped working in client environments over the years, and near the top is a category I'd call "the integration nobody remembers configuring." A backup job, a booking system, a CRM add-in installed by someone who left the company three years ago. Half the time these things are still talking to Exchange using an old protocol that most admins stopped thinking about once they finished their last migration project.
That protocol is Exchange Web Services, and its clock is running out. Not in some vague "eventually" sense either. Microsoft has published dates, and the first one is close enough that if you haven't looked at your tenant's EWS usage yet, now is the time.
What is actually changing
EWS has been around since Exchange 2007. It's a SOAP-based API that lets applications read and write mailbox data: messages, calendar items, contacts, tasks, free/busy info, and a fairly deep set of Exchange-specific operations that never got exposed anywhere else. For a long time it was the standard way for a third-party app to talk to an Exchange mailbox without going through MAPI or IMAP.
Microsoft announced in 2018 that EWS would stop receiving feature updates. That part is old news and most of us shrugged it off, because "no new features" doesn't mean "stops working." What changed the calculus was the Midnight Blizzard incident in January 2024, where EWS access was implicated in a breach against Microsoft's own corporate systems. After that, the retirement stopped being a slow background migration and became a scheduled shutdown with real dates attached, and the scope widened from just third-party apps to Microsoft's own products as well.
There's a middle option for tenants that need more runway. If you configure an AppID allow list and explicitly set EWSEnabled to true before the October cutoff, EWS keeps working for the apps on that list until the final shutdown in April. Microsoft has said they'll pre-populate an allow list based on observed usage if you don't do it yourself, but I wouldn't trust that to match what you actually rely on. Automated lists built from telemetry tend to catch the noisy stuff and miss the low-frequency scheduled jobs that only run once a quarter.
One thing worth repeating because people mix it up constantly: this only affects Exchange Online. On-premises Exchange Server is not part of this change. If you're running a hybrid environment, the on-prem side keeps EWS working exactly as it always has, which creates its own confusion when half your integrations still function and the other half don't.
What can actually break
This is the part that matters more than the dates. EWS touches more than people expect because it was the path of least resistance for a decade of tooling.
The obvious candidates are backup and archiving products. A lot of third-party backup solutions for Microsoft 365 mailboxes were built on EWS because it exposed granular item-level access that other APIs didn't have at the time. If a backup vendor hasn't finished their Graph migration, your nightly jobs could start failing silently, which is worse than failing loudly.
Booking and resource management systems are another common one. Meeting room booking displays, scheduling assistants, and free/busy lookup tools built before Graph matured often used EWS calendar operations directly.
Then there's the long tail: internal PowerShell scripts written years ago that pull mailbox statistics or export calendar data, custom CRM connectors that sync contacts, migration and export tools, compliance or eDiscovery tooling that does mailbox searches, and old on-prem monitoring agents that check mailbox health. None of these show up on anyone's radar until they stop working, because they run unattended.
Authentication is a separate failure mode worth calling out. Even before the hard disablement dates, a lot of EWS-based apps have been breaking because they still rely on Basic Auth or older NTLM-based flows, which Microsoft has been retiring on its own separate timeline. If an app is failing today, before October 2026, it's worth checking whether the actual cause is an auth protocol issue rather than EWS access itself. I've seen people assume the EWS retirement had already started when the real problem was Basic Auth being turned off in their tenant months earlier.
Applications I'd check first
If I were triaging a tenant today, I'd prioritize in roughly this order:
Backup and data protection tools: these run automatically and failures are easy to miss until you actually need a restore.
Any custom-built internal tool: anything written in-house is the highest risk because no vendor is pushing an update for you.
Migration and PST export utilities: if you're mid-project or planning one, this intersects directly with the deadline.
Calendar and room-booking systems: these tend to be visible and loud when they break, but that doesn't make them low priority.
Compliance, legal hold, and eDiscovery tooling: breakage here has regulatory implications, not just operational ones.
Old mobile device management or ActiveSync-adjacent tools: less common now, but they still turn up in older environments.
Microsoft's EWS Usage Reports, available in the Microsoft 365 admin center, will show you which app registrations are actually calling EWS in your tenant right now. That's a better starting point than guessing, because usage patterns rarely match what's documented anywhere. There's also an EWS Code Analyzer tool Microsoft released for scanning custom code for EWS calls, which is worth running against any internal scripts or applications your team maintains.
Microsoft Graph as the replacement
Graph is the unified API Microsoft wants everything to use going forward, covering not just Exchange but SharePoint, Teams, OneDrive, and the rest of the Microsoft 365 stack through one consistent REST interface with OAuth 2.0 and modern app registration. For most day-to-day mailbox operations, sending and reading mail, managing calendar events, working with contacts, it's a genuine improvement. The permission model is more granular, the auth flow doesn't rely on legacy protocols, and you get delta queries for efficiently syncing changes instead of polling everything repeatedly.
For a typical line-of-business app that reads a user's inbox or creates calendar events, moving to Graph isn't a huge lift. The concepts map reasonably well and the documentation is solid.
Where it's not a clean swap
This is where I'd push back on anyone treating Graph as a drop-in replacement, because it isn't, not yet.
Public folders are the biggest gap. Import and export of mailboxes made it into preview during 2025, but that explicitly excludes Microsoft 365 Groups and public folder mailboxes. If your organization still leans on public folders for shared calendars or departmental inboxes, and a lot of organizations quietly still do, there's no clean Graph equivalent for some of that access today.
Archive mailbox operations have had ongoing gaps. Delta queries for recurring calendar events are another area Microsoft has specifically called out as needing more work, which matters if your integration does anything with recurring meeting series rather than single events. User configuration data, things like certain mailbox-level settings, doesn't have full coverage yet either.
There's also an administration API gap. A lot of tenant and mailbox-level admin operations that EWS could do just aren't fully available through Graph yet, though Microsoft has an admin API in preview specifically to close that hole.
None of this means Graph migration should wait. It means the migration plan needs a parity check as its own step, not an assumption. Some of these gaps are closing on a rolling basis, so what's missing today might be covered by the time your project actually executes, but you can't assume that without checking current documentation at the time you do the work.
What I'd check before the October deadline
Practically, here's the sequence I'd work through on any tenant:
First, pull the EWS Usage Reports and get an actual list of what's calling EWS, rather than relying on institutional memory of what integrations exist. Second, for each item on that list, find out if the vendor has already shipped a Graph-based version, because a lot of major backup and archiving vendors have been actively working through this. Third, for anything custom-built internally, run it through the EWS Code Analyzer and budget real development time, not "we'll get to it," because Graph's permission model often requires different app registrations and consent flows than what the old EWS app had.
Fourth, decide on your allow list strategy before the end of August 2026, since that's the window Microsoft has flagged as the safe cutoff to configure EWSEnabled and an AppID allow list without risking an automatic, possibly incomplete, list being applied on your behalf. Fifth, if you find something depending on public folders or another known Graph gap, don't try to force a workaround, flag it and check current parity status closer to your actual cutover date since Microsoft has been closing these gaps incrementally.
Where migration projects fit in
Mailbox migration tooling is one of the categories worth checking carefully, because a fair number of migration and export utilities, especially older ones or scripts built for a specific one-time project years ago, were written against EWS since it exposed the granular mailbox access migration tools need. If you're planning a migration, whether that's on-prem Exchange to Exchange Online, cross-forest, or between different Exchange versions, it's worth confirming ahead of time whether the tool you're using has already moved to Graph-based access or still depends on EWS staying available. I ran into this while looking at options for an Exchange to Exchange Online project and noticed that EdbMails supports direct migrations between on-premises Exchange servers and Microsoft 365 without requiring PowerShell scripting, which at least removes one layer of custom scripting that would otherwise need its own EWS dependency check. Whatever tool you land on, confirm its current auth model as part of vendor selection rather than assuming it, since this is exactly the kind of detail that changes between versions. If you're weighing tools for an Exchange Migration, that's a reasonable point to add to your evaluation checklist alongside the usual concerns around downtime, mailbox mapping, and delta sync.
Beyond the tooling itself, migration projects can surface EWS dependencies you didn't know you had. Pre-migration assessment scripts, mailbox permission audits, and post-migration validation checks are all places where someone historically reached for EWS because it made a particular query easy. If a migration is already planned for sometime around the October 2026 to April 2027 window, it's worth treating the EWS retirement as part of the same project rather than a separate concern, since the two timelines are likely to overlap for a lot of organizations.
A practical checklist
- Run EWS Usage Reports in the Microsoft 365 admin center to see what's actually calling EWS in your tenant
- Run the EWS Code Analyzer against internal scripts and custom applications
- Contact every third-party vendor with an EWS-dependent product and get a written timeline for their Graph migration
- Identify anything touching public folders specifically, since that's the largest current parity gap
- Check whether any failures you're seeing right now are actually Basic Auth or NTLM related rather than EWS access itself
- Decide on an allow list strategy and configure EWSEnabled before the end of August 2026 if you need the extended runway
- Re-verify Graph parity status close to your actual cutover date, since Microsoft has been closing gaps on a rolling basis
- If a migration project is already scheduled, fold the EWS dependency check into that project's scope instead of treating it separately
- Document what you find, because six months from now nobody will remember which app needed which fix
Final thoughts
The EWS retirement isn't a surprise change, it's been telegraphed since 2018, but the concrete dates are what actually get people moving. October 2026 sounds distant right up until it isn't, and the applications most likely to break are exactly the ones nobody's watching: the scheduled job, the internal script, the integration installed by someone who's no longer around to explain it.
The good news is that the tooling to find these dependencies already exists, and Microsoft Graph handles the majority of common scenarios well. The part that takes actual discipline is going through the list methodically instead of waiting for something to fail in production and working backward from there.
