If your organisation runs Microsoft 365, something is about to stop working. From 1 October 2026, Exchange Online begins blocking Exchange Web Services (EWS), the API that a large share of backup tools, CRM connectors, helpdesk systems, signature managers and in-house scripts have used to reach mailboxes for fifteen years. On 1 April 2027 it is removed for good. Microsoft announced this in September 2023 and has repeated it since; the deadline for the tenant setting that avoids the October block was the end of August 2026. Most Indian tenants we speak to did not act on it, because the message went to an admin mailbox and the applications it affects belong to other departments.
This post is the practical version: the dates, what breaks, the allow list that buys time, and the decision to make before April. The same material with an inventory checklist and a 30-day plan is available as a free PDF: the EWS Retirement Runbook.
The dates
| Date | What happens |
|---|---|
| End of August 2026 | Deadline to configure an EWS app allow list and set EWSEnabled to True. Tenants that did so are excluded from the October automatic block. This has passed. |
| 1 October 2026 | Exchange Online starts blocking EWS. Tenants that left EWSEnabled unset are switched to False as the rollout reaches them. Admins can still re-enable EWS with an allow list. |
| 1 April 2027 | EWS removed from Exchange Online permanently. No re-enablement. |
Scope matters: this is Exchange Online only. Exchange Server on-premise, including Subscription Edition, keeps EWS. Hybrid organisations are affected for the mailboxes that live in the cloud.
What breaks
Outlook and phones are fine. The problem is every system that touches mail without a person in front of it:
- Backup and archiving tools that read mailboxes by EWS. Veeam has published its own notice; check each vendor you use.
- Journaling, compliance capture and eDiscovery connectors from third parties.
- CRM and ERP mail sync. Salesforce has its own EWS to Graph migration guidance; Dynamics, Zoho CRM, Tally add-ons and in-house connectors may all be on EWS.
- Helpdesk and ticketing systems polling a support mailbox.
- Signature managers, disclaimers, mail-merge and bulk-mail tools.
- HR, attendance and payroll systems that drop mail into a mailbox, and scanners configured against EWS.
- Custom applications written for Exchange years ago and pointed at the tenant during the 365 migration. These are the ones nobody remembers until they stop.
Inventory first, this week
- List every application, appliance and script that authenticates to Exchange Online. Start from Entra ID: enterprise applications and app registrations with Exchange permissions, plus service accounts with mailbox access.
- Pull the tenant EWS usage report and the Entra sign-in logs filtered to EWS for the last 30 days. Every application ID that appears is in scope.
- Ask each vendor in writing whether their product uses EWS, when the Graph version ships, and what the upgrade costs. Keep the replies.
- Search your own repositories and scheduled tasks for EWS endpoints and the EWS Managed API.
- Rank each item: business-critical, useful, or forgotten. The forgotten ones get retired, not migrated.
Buying time: the allow list
If EWS has been blocked on your tenant, an Exchange administrator can re-enable it until April 2027 by setting EWSEnabled to True and listing the application IDs that still need it in the tenant allow list. Only listed applications get through. Treat it as a bridge with an expiry date, log it as a change-control exception with an owner, and expect auditors under RBI, SEBI and CERT-In frameworks to ask why a retired protocol is enabled.
The decision: rewrite, replace, retire, or move
- Rewrite to Microsoft Graph for vendor products with a Graph version ready and for in-house code you will keep investing in. SaaS vendors quote five to seven months for a rewrite of authentication, throttling and sync state, and Microsoft itself notes that Graph still has parity gaps for some scenarios.
- Replace the integration on a standard protocol (IMAP, SMTP, CalDAV) or a vendor API when the application is old or the feature is small.
- Retire the forgotten ones. Most tenants find two or three.
- Move the mail platform if the rewrite list is long, the sector is regulated, or you do not want to run this exercise again at the next retirement.
Where XgenPlus fits, honestly
Every retirement in this cycle, basic authentication, EWS, the older Exchange editions, removes an interface your systems were built on and asks you to rebuild on the vendor's timetable. If you have a decade of integrations, that rebuild is happening either way. XgenPlus is enterprise email built in India, hosted in Indian data centres or on your own servers, and its integrations run on open, documented interfaces: IMAP and SMTP, CalDAV and CardDAV, ActiveSync, a documented SOAP API for provisioning, LDAP or Active Directory sign-in, and a RESTful API on the on-premise edition. None of them are on a retirement schedule.
Two honest limits. An XgenPlus migration is a project too, with an audit, a parallel run and a cutover evening. And your EWS code does not port to it unchanged; you replace the integration on a standard protocol, which is usually the smaller job. What changes is that it is the last such project, and the next Microsoft retirement notice is somebody else's problem.
Get the runbook PDF with the inventory checklist and the 30-day plan, or send us your tenant details for a migration scope you can put beside your Graph quotes. We reply within one business day.
Sources: Microsoft Learn, "Deprecation of Exchange Web Services in Exchange Online"; the Exchange Team blog posts "Retirement of Exchange Web Services in Exchange Online", "Exchange Online EWS, your time is almost up" and "Introducing EWSAllowedAppIDs"; Message Center MC676299 and MC1227454; Veeam KB4820; Salesforce EWS retirement guidance. Checked 8 September 2026. Microsoft can change dates; confirm against the Message Center for your tenant.
