EWS Deprecation and the Graph API Shift for Office 365 Migration
If you manage anything that touches Exchange Online programmatically — a migration tool, a backup product, a CRM connector, an in-house script someone wrote five years ago and forgot about — there's a date you need on your calendar: October 1, 2026. That's when Microsoft starts blocking Exchange Web Services (EWS) requests by default across Exchange Online tenants, with a full, no-exceptions shutdown following on April 1, 2027. This isn't a quiet sunset announcement that gets pushed back a few times. Microsoft has been explicit that this one is sticking, partly because of how central EWS turned out to be in the Midnight Blizzard security incident in early 2024. For anyone running an Office 365 migration project, this matters directly, because EWS has been the workhorse protocol behind a huge share of mailbox migration tooling for close to two decades. EdbMails Office 365 Migration has been actively aligning its Microsoft 365 connectivity with Microsoft Graph and modern authentication standards as this transition unfolds, precisely so a migration project doesn't get caught flat-footed by a protocol shutdown that's been telegraphed for years but is now genuinely arriving. Here's what's actually happening, the real timeline, and what it means for choosing or evaluating a migration tool right now.
What EWS Is, and Why Its Retirement Is a Big Deal
Exchange Web Services has been the primary API for reading and writing mailbox data — emails, calendar items, contacts, tasks — in both on-premises Exchange and Exchange Online since the mid-2000s. It's what a huge number of migration tools, backup products, and custom integrations have been built on top of, because for years it was simply the most complete way to interact with a mailbox programmatically.
Microsoft signaled the beginning of the end back in 2018, when it said EWS would stop receiving new feature investment in favor of Microsoft Graph. That alone didn't force anyone's hand — EWS kept working. What changed things was the Midnight Blizzard incident in January 2024, where a legacy OAuth test application with EWS-related permissions was used as part of a state-sponsored breach. That incident visibly accelerated Microsoft's urgency, and the scope of the deprecation effort widened from third-party applications to include Microsoft's own products as well.
The Actual Timeline
This is the part worth pinning down precisely, since a lot of secondhand summaries blur the dates:
- By the end of August 2026 — Tenants can proactively configure an EWS Allow List and set the EWSEnabled flag to True, which excludes them from the automatic blocking that follows in October. Microsoft will also pre-populate Allow Lists in September 2026 for tenants that haven't created their own, based on observed usage — though admins are encouraged to build their own list rather than rely on the auto-generated one.
- October 1, 2026 — Any tenant that hasn't explicitly opted to keep EWS enabled will have EWSEnabled automatically set to False. From that point, EWS calls are blocked for all applications in that tenant unless they're on an approved Allow List.
- Between October 2026 and April 2027 — Only explicitly allow-listed applications can continue using EWS. This window exists specifically to give organizations a final runway to complete migrations to Microsoft Graph.
- April 1, 2027 — EWS is fully and permanently disabled for Exchange Online. No re-enablement, no exceptions, no Allow List override after this date.
One detail that catches people out: this retirement applies only to Exchange Online. On-premises Exchange Server (2016, 2019, and the newer Exchange Server Subscription Edition) keeps full EWS support with no announced end-of-life for the protocol itself. If your environment is hybrid, that split matters a lot for how you plan around it.
Where Microsoft Graph Still Has Gaps
Microsoft has been candid that Graph API doesn't yet have full feature parity with EWS for every scenario, and that some gaps may never close. The areas most relevant to migration work specifically:
- Public folder import/export — Microsoft has stated outright that it will not provide APIs for programmatically creating, reading, updating, or deleting public folders after the October 2026 cutoff. This is one of the more consequential gaps for migration tooling, given how common public folder migrations still are.
- Microsoft 365 Groups import/export, and mailbox import/export more broadly, remain in preview status as Microsoft works through parity.
- Recurring event delta queries and a handful of narrower calendar/notes scenarios are also still catching up.
Microsoft is actively closing these gaps on a rolling basis, but the practical reality is that "Graph has full parity" isn't true everywhere yet, even as the EWS shutdown clock keeps ticking.
What This Means If You're Mid-Migration or Planning One
If your migration project runs past October 2026, or even close to it, the protocol your migration tool uses to talk to Exchange Online stops being a background detail and becomes something you actually need to ask about. A tool still leaning entirely on EWS faces one of three outcomes as the deadline approaches: it gets added to a tenant's Allow List as a stopgap, it transitions to Graph in time, or it stops working the moment a tenant's EWSEnabled flag flips to False.
Worth noting: needing EWS isn't inherently a red flag for a vendor right now — plenty of well-established tools are mid-transition, exactly per Microsoft's own published guidance to start now and migrate by the deadline. What matters more is whether the vendor has a visible, dated transition plan, rather than treating it as a someday problem.
How Migration Approaches Compare on This
| Approach | Current Protocol Reliance | Position Relative to the 2026/2027 Deadline |
| Legacy or unmaintained migration scripts | Built entirely on EWS, often years ago, with no active development | Highest risk — likely to break outright once a tenant's EWSEnabled defaults to False, with no vendor actively working on a Graph transition |
| Established third-party migration tools still EWS-dependent | Actively using EWS for core mailbox read/write operations | Many are publicly committed to migrating before the deadline, per Microsoft's own guidance — worth confirming a vendor's specific timeline rather than assuming |
| Tools already using or transitioning to Microsoft Graph and modern auth | Built around Graph API and OAuth 2.0 for Microsoft 365 connectivity | Best positioned, though still subject to Graph's own feature-parity gaps for things like public folder APIs |
| Hybrid environments with on-prem Exchange as source or target | Continue to support EWS for the on-premises side regardless of the Exchange Online timeline | Need to plan for a split protocol approach — Graph for the cloud side, EWS where on-prem Exchange remains in the picture |
The pattern across all of these: the EWS shutdown doesn't eliminate Exchange Online migration as a category — it just changes which protocol sits underneath it, and rewards tools that started adapting early rather than waiting for the deadline to force the issue.
How EdbMails Is Positioned for This Transition
EdbMails Office 365 Migration Software already connects to Microsoft 365 using OAuth 2.0-based modern authentication, and its Microsoft 365 connectivity is being actively aligned with Microsoft Graph as Microsoft's own parity work and deprecation timeline progress. The EdbMails development team is currently implementing Microsoft Graph API support internally, with a release planned in an upcoming update — so customers running migrations close to or past the October 2026 cutoff won't be left depending on a protocol Microsoft is actively shutting down. Here's where things stand today, alongside what's coming:
- Modern, OAuth-based connections to Microsoft 365 from the outset, rather than a legacy username/password-driven EWS setup — which puts EdbMails ahead of tools still running entirely on older authentication patterns tied to EWS.
- Active monitoring of Microsoft's published EWS deprecation timeline and feature-parity updates, so migration workflows can be adjusted as Graph API capabilities expand, rather than reacting after a tenant-level block already breaks something mid-project.
- Continued support for on-premises Exchange Server connectivity, which isn't affected by this Exchange Online-specific deprecation, for organizations running hybrid or on-prem-to-cloud migrations.
- Transparent migration reporting, so if a specific capability is affected by a protocol-level change during the transition window, administrators can see exactly what's happening rather than guessing at a generic connection failure.
This is an evolving area — Microsoft itself is still closing feature gaps in Graph on a rolling basis, and EdbMails' Graph API implementation is currently in active development rather than already shipped. The approach is to track Microsoft's parity work closely and release Graph-based connectivity as soon as it's been properly tested, rather than rushing out a partial implementation ahead of the deadline.
What Administrators Should Be Doing Now
- Inventory every application touching Exchange Online via EWS in your organization — migration tools, backup products, custom scripts, CRM connectors, anything. Microsoft's EWS Usage Reports in the admin center are the fastest way to see this.
- Ask any migration vendor directly about their Graph API transition timeline rather than assuming "still works today" means "will keep working past October 2026."
- If you're running a migration project that could extend past mid-2026, build the EWS deadline into your project timeline now rather than discovering it mid-project.
- For hybrid environments, plan separately for the on-premises Exchange side (unaffected by this deprecation) versus the Exchange Online side (directly affected).
- Don't wait for the August 2026 Allow List deadline to arrive before deciding what to do — Microsoft's own guidance is to start the audit and migration work well ahead of it.
- Watch for public folder-specific impact if your organization still relies on public folders, given Microsoft's explicit statement that programmatic public folder APIs won't be available via Graph after the cutoff.
Frequently Asked Questions
Does the EWS deprecation affect on-premises Exchange Server?
What happens if I do nothing before October 1, 2026?
Can I still use EWS after October 2026 if I need to?
Does EdbMails require EWS to function, and will it stop working after the shutdown?




