In September 2023, Microsoft declared the retirement of the EWS (Exchange Web Services) API within Exchange Online (the Microsoft 365 online stack) would occur in October 2026. This means any application currently dependent on EWS had a three-year deadline to fully transition to a supported alternative before this core service API is permanently retired. Depreciation of EWS was called back in 2018 when it was announced that they would no longer add features.
With only one year left in the originally three-year retirement, window, two-thirds of the time is already gone. If your EWS application migration work hasn’t started, you are now pretty much in the “red zone.” While nothing will fail today, if you miss the October 2026 deadline any application still using EWS will simply fail catastrophically with no easy recovery path. Probably worse if you haven’t left enough time to work out any issues your code has using the Graph API endpoint you’ll end up with a degraded application that causes a lot more support issues which ultimately lead to more cost.
If you look at the EWS migration period of 3 years as a whole it is now a lot easier to code a replacement application then it ever has before due to AI (whatever flavour you choose). But don’t underestimate the time the other phases such as planning, testing, fixing, deploying and documenting the changes takes, while AI is a game changer for the coding phase of a migration the amount of real world effort to get your app from one API to the other is significant and not to be underestimated.
Still waiting for a feature or the feature you need to use is still beta or Preview in the Graph
If you need to use the Beta endpoint in Graph to run your production code, one of the arguments you’ll face is about business risk. The argument is that even with EWS in its deprecated state, there is a greater support and service level risk in using a Graph Beta endpoint than in staying on EWS. The policies Microsoft has around this are listed in https://learn.microsoft.com/en-us/graph/versioning-and-support the one to highlight here
Like any other API in the beta endpoint, we can introduce breaking changes to APIs that are marked as preview without notice. Don’t access APIs from the beta endpoint in production apps.
In this instance however the impending EWS cliff and the time it takes to migrate your apps successfully outweigh the risk associated with the beta. For any ISV this is not really a great place to be in its a bit of a lose lose.
If your waiting for a key feature (like Online Archive access), at this point it’s like waiting for a bus that’s already late. You know the total migration project time is fixed, so the later that feature arrives, the more rushed and risky the rest of the work becomes. Instead of just waiting, start with what you have. For instance, if you can’t test with an Online Archive, try using a Shared Mailbox. This allows you to get as much of your code tested and validated as possible *before* the blocker is removed.
Don’t forget about OnPrem and issues with dependencies
If your application needs to support both On-Premises and Online environments, you now have no choice but to maintain EWS for On-Prem and Microsoft Graph for Online within your codebase. Which means duplication at points.
For codebases that have historically relied on the EWS Managed API and now want to adopt the Microsoft Graph SDK, the challenge becomes how to integrate modern Graph SDK libraries and references alongside legacy EWS libraries. This often means dealing with differences in authentication models, data structures, and API paradigms—all within the same solution.
EWS Managed API
Design Philosophy:
The EWS Managed API was introduced in an era where synchronous programming was the norm. Most operations (e.g.,FindItems,Bind,SendEmail) are blocking calls. When you call an EWS method in the EWS Managed API, the thread waits until the operation completes.
Microsoft Graph SDK
Modern Approach:
Built for cloud-first and scalable apps, the Graph SDK embraces async/await patterns throughout. Every network-bound operation (e.g.,graphClient.Users.Request().GetAsync()) is non-blocking. Async methods allow better resource utilization and responsiveness, especially in web apps and services.
Won’t they just extend the retirement date
There has been some strong messaging that this won’t be the case, there’s been a long enough period to think this will go ahead regardless and they will just count the casualties afterward. Any sort of reversal or partial allowance isn’t something you should count on.
Layoffs and Resource Constraints
Tech layoffs are now monthly occurrences across all sectors and layers, and when they happen, they can be very unexpected. (I can speak from experience on this one: when I started to write this post in early October, I had a job; by mid-October, the team I worked with, including me, was all laid off). If you’re yet to start your migration project, consider what you may need to do if you suddenly had half the resources you previously had to achieve it and a lot of the experience that originally built the code is no longer available.
For example:
Lean on AI hard to overcome any technical debt; the one thing it’s good at is explaining existing code.
Watch out for implementation hurdles if you don’t have experience in the existing codebase. Like the latest AWS outage demonstrated, simple things like DNS can cause big issues. AI is great, but it may not capture small intricacies in existing code that are there to deal with environment-specific issues. Chunking really large uploads and concurrent connection limits (e.g., in EWS) are examples.
Hidden EWS
While you might know about the major apps that are using EWS, it’s possible that EWS is also being used by other applications in your organization for infrequent activities. These could include applications sending email alerts or other seasonal activities like tax processing, semester scheduling, etc.
This means you might not notice any issues immediately after the October 2026 cut-off. However, when people return in the new year or perform that seasonal work, the application may fail. This is where a traditional report, like the EWS Usage Report, may not capture the application’s usage fully.
Call for Action
If your an ISV that is using EWS in an Application and you haven’t done anything the first thing I would suggest is googling (that thing you used before AI) EWS depreciation and read the statements put out by a lot of the other ISV’s. Some of these are quite good and it’s a duty of care you should have towards your customers to let them know of any potential for impact. The same goes if it’s just an a Line of business app in your organization. The next thing is start your migration next sprint the thing that happens after you go through the red zone is smoke, and as the old hardware joke goes: it’s incredibly hard to get the smoke back in once it’s escaped.