The EWS shutdown checklist covers what to finish in the final month

When I first wrote about the EWS shutdown in Exchange Online back in January (my earlier post on the EWS shutdown), a lot of tenants got busy for a while. Since then, though, nearly every organisation I've worked with still has a small, stubborn group of EWS integrations sitting on the inventory list. EWS will be blocked in Exchange Online in just one month, so this is the checklist I'd work through now: what to review, what to finish and what to monitor before October 1, 2026.

Leftovers from the January inventory still need a clear outcome

What surprised me most in almost every project was the number of third-party apps, tools and old scripts that were quietly using EWS. Many only turned up after thorough scanning, user complaints or plain luck. If your January inventory still has open items, close them out now. Every integration needs one of three outcomes: the migration is complete, you hold a written vendor statement (a casual email doesn't count), or the app or script has been formally retired. Go through the logs one more time as well. A forgotten service account or background job is often still sending EWS requests.

Vendor statements only count when you have them in writing

In a few projects, vendors simply answered "we're on Graph now" by email or in a support chat. I don't accept that. For every solution that is still live, get a written statement you can trace, ideally filed in a ticket system or project doc. You'll want it for the October cut-off and for audits later on. If something stops working after EWS is blocked, you need proof that the vendor claimed to be compliant. For in-house scripts, write down clearly whether each one was retired or migrated.

Scripts have to move to Graph PowerShell and new workflows

Plenty of automation still runs on EWS, mostly for mailbox and calendar tasks, and ApplicationImpersonation. Moving it to Microsoft Graph PowerShell can turn into a sizeable project, particularly when you hit permission models or authentication flows you haven't worked with before. Read Microsoft's official migration guide before you start. Graph now covers most mailbox and calendar scenarios, but the details trip people up: scopes differ, token handling differs, and you need app registrations. If you run mailbox reports or automation, test the new flows properly with the authentication you use in production (service principals, MFA and so on).

Practical tip: Test migrated scripts in an environment that mirrors production, with real MFA and the service account you actually intend to use. Basic auth still hides in forgotten corners, even now.

A test plan and early communication decide who feels the pain first

Don't wait until October 1 to discover what breaks. Write a clear test case (manual or automated) for every system or integration you replaced, and name someone to run it after the cutoff. Brief business owners and the helpdesk ahead of time. Better still, have them run their own checks so support isn't buried on day one. A bit of communication now means fewer incidents later.

Sign-in failures and helpdesk tickets need watching on October 1

Once EWS is blocked, keep an eye on two things: a jump in helpdesk tickets and sign-in failures for apps and service principals. In Microsoft Entra ID, the sign-in logs are where failed EWS access attempts show up. With Entra ID P1 or P2 and logs exported to Log Analytics (role: Security Reader), run this KQL query in your Log Analytics workspace (Logs blade):

SigninLogs
| where AppDisplayName contains "Exchange Web Services"
| where ResultType != 0
| project UserPrincipalName, AppDisplayName, ClientAppUsed, ResultDescription, TimeGenerated

The query lists failed EWS sign-ins as they happen, which is exactly what you need for troubleshooting on day one.

Make sure the helpdesk knows the most common error messages and how to escalate them. Also keep in mind that the EWS shutdown only affects Exchange Online. EWS in on-premises Exchange is not affected, and you'll hear that question a lot.

This simple flowchart shows the process for the final month:

flowchart TD
    Inventory["EWS app inventory done?"] -->|"yes"| Migration["Migration/retirement complete?"]
    Migration -->|"yes"| Test["Test case documented?"]
    Test -->|"yes"| Comms["Business owners informed?"]
    Comms --> Monitoring["Monitoring ready for cutoff?"]

Figure: The path from inventory to real-time monitoring before the EWS shutdown in Exchange Online.

I double-check everything and then check it again

The EWS users that hang on longest are rarely the obvious ones. Somewhere there's nearly always a forgotten connector, script or account, and decentralised environments are the worst for this. If you're unsure, check twice. That beats missing the one integration that takes down something important. What matters most is a clear plan for communication and monitoring around the cutoff. Work through this checklist now and October 1 shouldn't hold many surprises. And if someone really does still need EWS? On-premises Exchange isn't affected, but make sure there's a good reason for keeping it.