A Toronto accounting firm may never have built an Exchange integration, yet its appointment scheduler can still read calendars through Exchange Web Services. A multifunction printer may not use EWS, while a help-desk platform, CRM add-in, email archive, backup product, room-booking tool, or custom reporting script does. That is why an EWS retirement project begins with discovery rather than a single configuration change.
Microsoft states that phased disablement of Exchange Web Services in Exchange Online begins in October 2026 and that EWS is scheduled to be fully disabled in April 2027. The change is specific to Exchange Online. Microsoft Graph is not supported for Exchange on-premises, and Microsoft explicitly separates on-premises Exchange EWS from this cloud retirement.
The business risk is not simply that an old API disappears. It is that a quiet dependency may stop synchronizing customer email, creating tickets, reading a shared calendar, archiving messages, or moving data between systems. A useful plan identifies what is calling EWS, who owns the process, which Exchange actions it performs, whether the vendor has a supported replacement, and how the new path will be tested before the old one is removed.
What Microsoft is changing—and when
EWS is a SOAP-based API introduced with Exchange Server 2007. Applications use it to work with messages, folders, calendars, contacts, availability, attachments, mailbox settings, notifications, synchronization, and other Exchange data. Microsoft stopped active investment in EWS for Exchange Online in 2018 and recommends Microsoft Graph for cloud mailbox integrations.
| Date | Microsoft milestone | Practical business action |
|---|---|---|
| Now through September 2026 | EWS remains available, subject to tenant, mailbox, application, and Microsoft controls | Complete discovery, vendor decisions, development, testing, and ownership |
| October 2026 | Phased EWS disablement begins globally for Exchange Online organizations | Have production replacements ready and a controlled exception process for known dependencies |
| October 2026 to March 2027 | Organizations progress through the retirement phase | Remove remaining exceptions, monitor Graph workloads, and confirm business outcomes |
| April 2027 | Microsoft plans full EWS disablement in Exchange Online | No Exchange Online business process should depend on EWS |
Do not confuse EWS retirement with SMTP AUTH retirement. EWS is an API used to access Exchange mailbox and calendar capabilities. SMTP is a mail-submission protocol. An application might use EWS, SMTP, Microsoft Graph, or more than one of them. Inventory the actual protocol and authentication path instead of assuming that every system that sends email is an EWS dependency.
Where EWS dependencies commonly hide
Small organizations often inherit integrations through products rather than source code. The vendor may call the setting Microsoft 365 sync, Exchange connection, calendar integration, mailbox polling, service account, Office 365 connector, or email capture without mentioning EWS in the interface. Treat every product that reads or changes mailbox data as a candidate until its documentation or observed traffic proves otherwise.
- Customer relationship management systems that capture email or synchronize appointments.
- Help-desk and ticketing tools that monitor a shared mailbox or create replies.
- Backup, archive, eDiscovery, journaling-adjacent, and migration products.
- Room, resource, field-service, healthcare, legal, and professional-services scheduling tools.
- Custom .NET, PowerShell, Java, PHP, Python, or integration-platform code using EWS endpoints or libraries.
- Reporting, compliance, workflow, and robotic-process automation that reads mailboxes or calendars.
- Older add-ins, line-of-business software, voicemail systems, and synchronization agents.
- Service accounts and Entra applications with Exchange-related delegated or application access.
1. Export the Microsoft 365 EWS usage report
In the Microsoft 365 admin center, go to Reports, Usage, Exchange, and the EWS usage tab. Microsoft says the report shows active application IDs, the EWS SOAP actions each application used, call volume, and last activity date. Review the 90-day view and export the CSV so it can become a working inventory rather than a screenshot owned by one administrator.
For each application ID, look in Microsoft Entra enterprise applications and app registrations. Record the display name, publisher, owners, permissions, credentials or certificates, sign-in evidence, and assigned users where relevant. An unfamiliar identifier is a research task—not proof that the application is safe to delete.
| Inventory field | Why it matters | Example evidence |
|---|---|---|
| Application ID and product | Connects telemetry to an owner and vendor | EWS report, Entra app, vendor console |
| Business process | Shows the effect of failure | Appointments, ticket intake, archive, CRM sync |
| Mailboxes and data | Defines scope and sensitivity | Shared support mailbox, executive calendars |
| SOAP actions | Guides Graph API mapping and tests | FindItem, GetItem, SendItem, Subscribe |
| Activity pattern | Prevents missing infrequent workloads | Continuous, month-end, quarterly, incident-only |
| Technical and business owners | Creates decision and testing accountability | Vendor contact, internal system owner |
| Replacement and deadline | Turns discovery into execution | Vendor Graph release, custom migration sprint |
2. Expand discovery beyond the report
Search source repositories and configuration stores for terms such as ExchangeService, EWS Managed API, exchangelib, php-ews, Exchange.asmx, EWS endpoint URLs, SOAP action names, and old service-account addresses. Review secrets vaults, scheduled tasks, automation servers, integration platforms, VM inventories, app registrations, conditional-access exclusions, and vendor documentation.
Ask process owners a business question: which tools read, create, synchronize, archive, or search email and calendars? That wording finds dependencies that a protocol question misses. Include finance, sales, support, operations, human resources, legal, and any managed service provider. Give each discovered workflow a consequence rating based on customer impact, revenue, legal or retention need, privacy, operational delay, and availability of a manual workaround.
3. Choose the correct path for each dependency
| Dependency | Preferred path | Decision evidence |
|---|---|---|
| Supported third-party product | Upgrade or reconfigure to the vendor's Graph-based release | Supported version, exact feature coverage, permissions, test instructions, date |
| Custom application with Graph parity | Refactor to Microsoft Graph and modern application identity | Mapped operations, permission model, performance and error handling tests |
| Workflow suited to Power Platform | Rebuild with a supported Microsoft 365 connector where architecture and licensing fit | Connector authentication, limits, ownership, DLP policy, support model |
| Obsolete or unused integration | Retire it and remove credentials, access, jobs, and documentation | Owner approval, usage evidence, rollback window, post-removal monitoring |
| Temporary parity or vendor gap | Document a time-limited EWS exception with an exit plan | Business justification, least access, named owner, milestones, final cutoff risk |
A vendor statement that a product supports Microsoft 365 is not enough. Ask whether the exact feature and version uses Microsoft Graph instead of EWS, which Graph permissions it requests, whether it uses delegated or application access, how access is limited to required mailboxes, what changes for shared mailboxes and calendars, and when the supported release will be generally available.
4. Map EWS operations to Microsoft Graph
Microsoft publishes an EWS-to-Graph mapping for common message, folder, attachment, inbox-rule, MailTips, out-of-office, notification, synchronization, calendar, contact, and group operations. Use the application's observed SOAP actions to create a functional map. A one-to-one API name match does not guarantee identical paging, identifiers, notification behaviour, throttling, consistency, recurrence handling, or error semantics.
- List each EWS operation and the business outcome it supports.
- Identify the corresponding Graph endpoint or supported alternative.
- Record known parity gaps and decide whether the workflow can change.
- Choose delegated access for a signed-in user or application access for an unattended workload based on the actual operating model.
- Request only the Graph permissions needed for the mapped operations.
- Define mailbox scoping, consent, credential, certificate, and secret-rotation controls.
- Design for Graph paging, delta queries or change notifications, throttling, retries, expiration, and idempotency.
- Create tests from real business scenarios before changing production traffic.
Microsoft Graph uses OAuth 2.0 and provides more granular permission options than EWS's broad access model. That improvement is not automatic. Application permissions can still be powerful, and tenant-wide admin consent can create excessive reach if the design does not constrain access. Document why each permission is required and test with a mailbox the application should not be able to access.
5. Test business outcomes, not only API responses
A successful HTTP response proves very little about the complete workflow. Build a representative test set for shared mailboxes, delegated calendars, recurring meetings, attachments, large folders, daylight-saving transitions, duplicate prevention, message flags, permissions, notification renewal, throttling, retries, and recovery after an interrupted run. Use non-production data or an approved test tenant where possible.
- Compare record counts, timestamps, identifiers, attachments, and status fields between old and new paths.
- Verify the process cannot read a mailbox outside its approved scope.
- Test expired secrets or certificates, revoked consent, throttling, network interruption, and retry behaviour.
- Measure latency and backlog under expected peak volume rather than a single sample request.
- Confirm logging contains application, operation, correlation, outcome, and actionable error context without exposing sensitive content.
- Have the business owner execute the real workflow and sign off on the result.
6. Run a controlled cutover and remove old access
Choose a cutover window based on process risk, not administrator convenience. Define who can stop the change, how data written during the transition will be reconciled, what constitutes success, and how long the old path may remain available. Parallel running can help compare read-only or synchronization results, but two systems that both create, send, delete, or update items can introduce duplicates and race conditions.
After acceptance, disable the EWS path, revoke unneeded permissions and consent, remove service-account access, retire secrets and certificates, stop scheduled jobs, update runbooks, and monitor the business process. Leaving the old identity active as an indefinite fallback preserves the security exposure and makes later ownership harder.
How to use EWSAllowedAppIDs as a temporary control
Microsoft introduced EWSAllowedAppIDs to let administrators maintain an application ID allow list during the final retirement phase. Microsoft's June 2026 guidance explains that phased tenant changes begin in October and that the allow list can restrict EWS to identified applications when the tenant is configured for that model. This is useful for reducing unknown access while known dependencies are completed.
Treat the allow list as controlled scaffolding. Adding an application does not validate its security, confirm its owner, provide Graph parity, or extend EWS beyond final retirement. Record the reason, app ID, mailboxes, owner, approved date, review date, compensating controls, migration milestone, and removal deadline for every entry. Avoid broad re-enablement merely to restore an unidentified application after a failure.
A practical 60-day plan before October
| Period | Main work | Evidence of completion |
|---|---|---|
| Days 1–10 | Export 90-day usage, inspect Entra apps, search code and configuration, interview owners | Prioritized inventory with app IDs, actions, mailboxes, owners, and impact |
| Days 11–20 | Contact vendors, classify retire/upgrade/rebuild/exception paths, confirm Graph gaps | Decision and dated plan for every active dependency |
| Days 21–40 | Upgrade products, refactor code, redesign permissions, and build monitoring | Testable replacement in a controlled environment |
| Days 41–50 | Run functional, security, volume, failure, and business-acceptance testing | Recorded results, defects resolved, owner sign-off, cutover plan |
| Days 51–60 | Cut over priority workloads, revoke old access, configure justified temporary controls | Production evidence, monitored outcomes, exception register with exit dates |
Questions to send every affected vendor
- Does our exact product version and enabled feature use EWS against Exchange Online?
- Which release replaces EWS, and is that release generally available and supported today?
- Does the replacement use Microsoft Graph, another supported API, or a changed product workflow?
- Which delegated or application permissions are required, and can access be limited to selected mailboxes?
- Are shared mailboxes, archives, recurring calendars, attachments, notifications, and our current volume supported?
- What configuration, licensing, downtime, data migration, and user training are required?
- How can we prove that EWS traffic has stopped after the change?
- What is the vendor's support and escalation plan during Microsoft's phased disablement?
Common EWS retirement mistakes
- Checking only the last seven days and missing infrequent jobs.
- Assuming a Microsoft 365 label in a vendor portal means the feature already uses Graph.
- Migrating authentication to OAuth but leaving the application on EWS, which does not solve EWS retirement.
- Granting broad Graph application permissions without mailbox scoping, ownership, or periodic review.
- Testing basic email and ignoring calendars, shared mailboxes, notifications, recurrence, attachments, or scale.
- Re-enabling EWS for the entire tenant to fix one unidentified dependency.
- Keeping old service accounts, credentials, consent, and scheduled jobs after cutover.
- Treating April 2027 as the project start date instead of the final boundary.
The bottom line
EWS retirement is a business-continuity and access-governance project disguised as an API change. The difficult part is rarely finding Microsoft's deadline. It is connecting an application ID to a product, a product to a business process, and that process to an owner who can decide, test, and accept a replacement.
Canadian small businesses should use the remaining time before October to build evidence, prioritize customer-facing and regulated workflows, and migrate supported Exchange Online scenarios to Microsoft Graph with deliberate permissions. A temporary allow list can keep a known dependency controlled during transition, but the durable result is a supported integration, documented ownership, useful monitoring, and no EWS traffic left to surprise the organization in 2027.