Microsoft 365 Migration: 5 Critical Checks for the EWS Retirement

If your business runs anything that talks to Exchange Online over EWS — a backup tool, a CRM connector, a signature manager, an archiving product — Microsoft is closing that door on a published schedule. Where you sit on that schedule decides what you should do today, and it is why this belongs on the Microsoft 365 migration roadmap rather than in a mailbox ticket.

Last reviewed 12 August 2026. This post is organised by when you are reading it rather than around one deadline, because the retirement runs in phases and the right action changes at each one. Every date below comes from Microsoft’s own message centre posts and documentation, linked as we go.

Where your Microsoft 365 migration sits on the EWS timeline

Exchange Web Services has been on notice since 2018, and Microsoft set the disablement date to October 2026 back in 2023. The date is the part everyone remembers. The mechanism is the part that catches people out.

EWS is not switching off in a single event. It is being closed in stages, and each stage changes what the correct next move is:

• Until 31 August 2026. Configure the application allow list. Cheapest path, still fully open, and it takes your tenant out of the automatic change that follows.
• 1–30 September 2026. Past Microsoft’s stated guidance window but before enforcement. Still worth doing, with one caveat.
• 1 October 2026 – 31 March 2027. Enforcement is running. Applications that are not listed are already failing. Migration is the work; the allow list is triage.
• From 1 April 2027. Gone permanently, with no re-enablement. Only a product change or a move to Graph helps you.

What Microsoft has actually said

The sentence everyone quotes comes from message centre post MC1227454, published 5 February 2026: “If EWS is required after October 2026, configure an AppID AllowList and set EWSEnabled=True before end of August 2026.”

The same post sets both ends of the process. Phased disablement begins on 1 October 2026, and after 1 April 2027 access is permanently removed with no re-enablement. It also warns that temporary “scream tests” — short windows where EWS is turned off and back on to force dependencies into the open — may happen before October.

The allow list is real and shipped. MC1447678, published 5 August 2026, records EWSAllowedAppIDs as generally available worldwide since late July 2026, and gives that message an act-by date of 30 September.

One line in it matters more than the rest. Before October, EWSEnabled=True with an empty list allows everything. From October, that identical configuration blocks everything. Turning EWS on without naming the applications stops being permissive and quietly becomes a block-all.

Microsoft also states that a tenant with EWSEnabled=True and a configured allow list will not have that setting changed by Microsoft before April 2027. That is the protection you are actually buying, and it is the one fixed point a Microsoft 365 migration plan can be built around.

Reading this before 31 August 2026

Do the allow list. It is reversible, it is quick, and it is the only action on this page that costs almost nothing.

Run the EWS usage report in the admin centre first, so the list you build reflects what your tenant genuinely calls rather than what you assume it calls. Then set the application IDs and enable the protocol explicitly:

Set-OrganizationConfig -EwsAllowedAppIDs "<appid>,<appid>"

Read it back with Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy. Microsoft’s own announcement of the feature is blunt about a sharp edge: the cmdlet writes the whole value, and there is no incremental add or remove. To change one entry you read the current list, recompute it, and write it back complete. Automate that or you will drop an application by hand.

One confusion worth heading off. The older EwsAllowList is matched on user agent, not application ID, and it is a different setting from EWSAllowedAppIDs. They can be used together. They are not interchangeable, and a Microsoft 365 migration plan that treats them as one thing will produce a list that looks configured and blocks nothing.

Reading this in September 2026

You have missed Microsoft’s stated window, and it is not fatal. Enforcement has not started, the pre-October behaviour still applies, and configuring the list now still works.

What you have lost is the guarantee of doing it yourself. Microsoft has said it will populate allow lists in September for tenants that have not, based on the EWS usage it observes — and a list generated from observed traffic will include whatever happens to be calling, including the forgotten script and the tool nobody has owned since 2021. A list you wrote yourself is not overwritten.

So the September action is the August action, done immediately, plus one extra step: read the list back after you set it and confirm nothing arrived in it that you would not consciously approve. That review is worth an hour of anyone’s time. A Microsoft 365 migration that starts here is behind, not lost.

Reading this between October 2026 and March 2027

Enforcement has begun. If something in your estate broke and the symptom is an HTTP 403 against Exchange Online, this is the first thing to check rather than the last.

The allow list still works in this window, and admins can still re-enable EWS, so the immediate fix has not vanished. But the framing has changed: you are now restoring service on borrowed time rather than preparing calmly, and every week spent here is a week not spent on the actual replacement.

Treat the configuration as an incident response step and the migration as the real project. In this phase a Microsoft 365 migration plan that consists only of allow-list entries is not a plan — it is a countdown with better paperwork.

Reading this from April 2027 onward

There is no configuration answer left. Microsoft has been explicit that access is permanently removed with no re-enablement, so a tenant setting cannot help you and neither can a support case.

What remains is product work: the vendor ships a version that uses Microsoft Graph, you replace the product, or you rewrite the bespoke integration. If you are here and still discovering dependencies, the honest sequence is to inventory what broke, rank it by business impact, and buy or build your way out in that order. A Microsoft 365 migration begun at this point is remediation, and it deserves to be resourced as one rather than squeezed into a maintenance window.

The lesson is worth taking properly, because the next protocol retirement is already being drafted somewhere.

Five checks that hold at any point in a Microsoft 365 migration

Wherever you are on the timeline, these five are the same work in a different order.

1. Find out whether you use EWS at all

Most businesses genuinely do not know. EWS is rarely something you chose — it is something a product you bought happens to use underneath.

The admin centre usage report shows which applications made EWS calls and how often. Start there. It takes minutes and it either ends the exercise or starts it. If the report is empty, write down that you checked and the date you checked, because “we looked and found nothing” is a much better answer in six months than silence.

2. Name the applications, not just the counts

A usage report gives you application IDs. Turning those into product names is the work.

The usual offenders are backup and archiving tools, email signature managers, CRM and helpdesk integrations, migration utilities left connected after a project ended, and bespoke scripts written by someone who has since left. That last category is the one that bites. Any Microsoft 365 migration that inherited scripts from a previous provider should assume there is at least one nobody has looked at in years.

3. Ask every vendor for their date, in writing

For third-party products the fix is not yours to implement. It is theirs to ship and yours to chase.

Ask a specific question: which version removes the EWS dependency, and when is it generally available? A vendor who cannot answer that in 2026 is telling you something useful about the rest of the relationship. Keep the replies — the difference between an incident and a negligence conversation is whether you can show you asked.

4. Check the dependencies that are not applications

Two of them catch people who were sure they had no EWS footprint.

Kiosk and frontline licences are one. MC1191578 blocks EWS for mailboxes licensed only with Exchange Online Kiosk or Microsoft 365 and Office 365 F1 and F3, returning HTTP 403 — and note that Microsoft moved that date from 30 June 2026 to 1 October 2026 in a June update. Published dates do move, in both directions, which is the whole argument for checking the source rather than a blog post.

Cross-tenant collaboration is the other. Free/busy sharing, MailTips and calendar sharing with other Microsoft 365 organisations run over EWS today and move to the Cross-Tenant Access Policy, available from September 2026. Get-OrganizationRelationship and Get-AvailabilityAddressSpace tell you in seconds whether that applies to you.

5. Check what Graph does not yet cover

Microsoft Graph is the replacement, and for most scenarios there are direct mappings from EWS operations to Graph APIs. Most, not all.

Microsoft’s published roadmap still lists parity gaps: import and export of public folders and of Microsoft 365 Groups, in-place archive handling, event delta for recurring events, sticky notes, and some administration APIs still in preview. If your dependency sits in one of those, you need the allow list and a longer plan, and you want to know that now rather than in March 2027.

Why this is a governance problem, not a mailbox problem

It is tempting to treat this as an Exchange task. It is not.

The reason most businesses discover an EWS dependency late is the same reason they discover most things late: nobody maintains an inventory of what integrates with what. The tool that surfaces this is not an admin console, it is a documented estate.

We make the same argument in our piece on what a virtual CIO actually does — the unglamorous inventory work is what makes every subsequent decision cheap. This retirement is a clean demonstration of the cost of skipping it.

Two businesses with identical estates have very different years. The one with an integration register spends an hour. The one without spends three weeks discovering what it owns, and does it under a deadline set by somebody else.

The escalation traces back to a specific incident. Microsoft’s documentation notes that the Midnight Blizzard intrusion in January 2024 involved EWS, which raised the urgency and widened the scope from third-party applications to Microsoft’s own products. This is not a routine API refresh. It is a security programme with a hard stop, and it will not be the last one.

When the allow list is the wrong answer

The unprofitable thing to say, so we will say it: not every Microsoft 365 migration needs an allow list at all.

If the usage report shows one application, that application has a Graph-based version available, and upgrading it is a morning’s work, do not build an allow list at all. You would be adding a tenant-level configuration, a review date and a removal task to avoid a change you could simply make.

If the only EWS traffic in the report is a tool you no longer use, the answer is to decommission it, not to authorise it. An allow list entry for an abandoned product is a permission with no owner, which is exactly the class of thing that turns up in an incident review.

And if you cannot identify what is calling, do not allow it because the report shows traffic. Find out first. An allow list assembled by pasting in every application ID you can see reproduces the unrestricted access the retirement exists to end.

The documentation habit this should leave behind

The most valuable output of this exercise is not the allow list. It is the integration register you have to build in order to produce one.

Write down, for every application that touches your tenant: what it is, who owns it commercially, which permissions it holds, which protocols it uses, and when you last verified any of that. Keep it with your estate documentation rather than in an email thread. Then remove entries as each application is fixed, so the list shrinks toward nothing rather than freezing at its maximum.

The same register does other work. Every one of those integrations holds permissions against your data, which makes it the starting point for reviewing whether those permissions are still appropriate — a theme we pick up in our analysis of why identity attacks now beat software exploits. It is also the document that tells you which restores actually matter when you run a restore drill.

Basic authentication went the way EWS is going. So did older TLS versions. Anything that predates modern identity controls is on a clock, published or not, and the businesses that handle each announcement in an afternoon are the ones that did this inventory once and kept it current.

That is the argument for treating a Microsoft 365 migration as governance work rather than as an Exchange task, and it is the part of this post that will still be true long after every date on it has passed.

Treating it that way is also how we scope Microsoft 365 migration work: discovery first, as its own fixed piece, ending in a written plan and a real number rather than a quote guessed before anyone looked.

The licensing baseline is part of that same discovery, because a Microsoft 365 migration fixes the plan mix at the moment it is cheapest to change. Our comparison of Business Premium against Microsoft 365 E3 covers what Microsoft’s 1 July 2026 pricing and packaging update did to that decision.