Exchange Online EWS Retirement: What to Check Before October 1

If your CRM can send an email today, that does not tell you whether its mailbox connection will survive October. Sending, syncing replies, updating calendars, and importing messages can depend on different parts of an integration. An old dependency can stay unnoticed until the particular job that uses it runs.

Microsoft begins its phased Exchange Web Services disablement in Exchange Online on October 1, 2026. EWS will be fully and permanently disabled on April 1, 2027. This applies to Exchange Online; Microsoft is not retiring EWS in on-premises Exchange Server through this change. Those distinctions matter when a vendor says it has handled “the EWS deadline.” Microsoft's retirement update explains both stages.

Check the Actual Mailbox Connection

Start with the tools that touch your Exchange Online mailboxes. Ask each owner or vendor which API the deployed integration uses, whether it still makes any EWS calls, and which version removes those calls. Get the answer for your installed version and enabled features.

“We support Microsoft Graph” leaves room for an older connector, an optional calendar feature, or an export job to keep using EWS. A useful answer names the remaining dependency, the replacement, and a date when you can test it.

Include work that runs less frequently than your normal sales sequence. A month-end export or occasional mailbox import needs an owner even if nobody has opened its dashboard recently. Test the jobs your team depends on, including reply handling and failure notifications, instead of stopping after a successful send.

Review the Application Allow List

Microsoft's September guidance says administrators should review EWS usage and configure EWSAllowedAppIDs for applications that still need access, with EWSEnabled set to True. The behavior rolls out tenant by tenant from October 1. Microsoft's retirement update puts the preparation deadline at the end of September.

For tenants without a configured list, Microsoft describes an automatic list based on the preceding 60 days of usage. It can miss infrequent applications and include applications the business no longer wants. Microsoft says it will preserve a customer-managed list. Read its September 4 allow-list guidance before making changes.

Have the person responsible for Exchange administration reconcile that list with application owners. For each active application, confirm the current business need and name the person supporting it during migration.

Ask for a Workflow Test

A migration plan should name what happens to existing connections, permissions, stored messages, and scheduled jobs. Ask the vendor to demonstrate the workflows you use, then run your own check with an ordinary user account and representative test data.

Do not assume every EWS function has a direct Graph replacement. Microsoft's migration roadmap lists remaining gaps, target dates that can change, and capabilities it does not plan to add. If your application depends on one of those functions, the vendor needs to explain the revised workflow.

Temporary EWS access should also have an owner and a removal date. Otherwise, the team that gets the connection working again can leave the actual migration unfinished.

Put Integration Ownership in the Purchase Decision

This is the kind of question we want buyers to ask when they evaluate email infrastructure: who identifies a provider change, tests its effect, and owns the repair? An inbox count does not answer it.

Our Mailrun infrastructure comparison includes the operating responsibilities worth checking with any provider. If your team uses Exchange Online, add EWS migration status to its integration inventory before October. Record the remaining dependency, its owner, and the replacement test date so the team can see which work is still open.