EWS goes dark in October, and your migration tool probably still uses it

Exchange Web Services has been the quiet workhorse behind an enormous amount of third party tooling for over a decade. On 1 October 2026 it starts being switched off, and on 1 April 2027 it stops existing.

The part that catches people is not the date. It is that most organisations do not know what they are running that depends on it.

The two dates and what each one does

1 October 2026. Phased disablement begins. Tenants that did not explicitly opt out get EWSEnabled=False. Admins can still re-enable it and approve specific applications through an AppID allow list, so this is a hard stop with an escape hatch.

1 April 2027. Permanent retirement. No allow list, no re-enabling, no exception process. Anything still on EWS stops working and the recovery is a migration, not a setting.

The six months between them is the entire buffer. It is not extra time to decide, it is time to execute a change you should already have scoped.

What is actually using it

This is the real work, and it is unglamorous. The usual suspects in an estate I have looked at:

• Migration and archiving tools. Many mailbox migration products still default to EWS because it worked and there was no reason to change. If a cutover is planned for late 2026 or 2027, check this before you plan anything else.
• Backup and eDiscovery products. Especially older on-premises appliances whose vendor roadmap moved on before your renewal did.
• Room and resource booking. Meeting room panels, desk booking systems, digital signage in reception. These are bought by facilities, not IT, and they never appear on an application inventory.
• CRM and helpdesk integrations. Anything that reads a shared mailbox to create tickets.
• Scripts nobody owns. The scheduled task on a server that mails a report, written by someone who left in 2019.

That third one is the one I would look at first. Room booking panels are physical objects on walls, bought on a facilities budget, and when they stop showing meetings the complaint arrives at IT with no context and no vendor contact.

Find it before you plan it

The Microsoft 365 admin centre publishes EWS usage reporting, and Microsoft has released scripts for deeper analysis. Start there rather than with an application inventory, because the inventory records what was bought and the usage report records what is actually calling.

Sort by application ID and volume. The high volume callers are usually obvious and already known. The interesting entries are the low volume ones, because those are the scheduled jobs that run monthly and will fail in a way nobody connects to a date six weeks earlier.

The move is to Graph, and it is not a swap

Microsoft Graph is the replacement, but treating this as a protocol substitution understates it. Graph has a different permission model, and this is where projects lose their schedule.

EWS applications frequently used impersonation with broad access across mailboxes. Graph pushes toward granular application permissions with scoped access policies, which is better and is also a security review, a set of approvals, and a conversation with whoever owns the tenant's app registrations. Budget for that conversation, not just for the code.

What I would do between now and October

• Pull the EWS usage report this week. Not next month.
• Name an owner for every calling application, including the ones owned by facilities and finance rather than IT.
• For anything with a vendor, get their Graph migration position in writing with a date. A vendor who cannot answer this by now is a vendor you are replacing.
• Decide deliberately whether to set the allow list. If you do, treat it as a dated exception with a review, not a resolution.
• Assume the April 2027 date is real, because unlike most deprecations this one has an explicit no re-enabling clause.