Microsoft has set a firm deadline for the retirement of Exchange Web Services in Exchange Online, with global disablement beginning in October 2026 and a full shutdown by April 2027. The move forces organizations reliant on legacy integrations to migrate to Microsoft Graph or risk service disruptions.

The Shutdown Plan: A Two-Phase Countdown

Exchange Web Services, the SOAP-based API that has powered email client apps, compliance tools, and line-of-business integrations for decades, will stop functioning in Exchange Online on a precise schedule. According to Microsoft's advisory, the retirement unfolds in two stages:

  • October 1, 2026: Global disablement begins. For newly created tenants, EWS will be disabled by default. For existing tenants, Microsoft will start blocking EWS requests from applications that have not been explicitly allowed by an administrator, unless the tenant is in a temporary exemption window.
  • April 1, 2027: Full disablement completes. All EWS requests will be blocked across all Exchange Online tenants, regardless of exemptions or allow-lists. No new exemptions will be granted after this date.

The timeline leaves organizations with roughly 18 to 24 months to inventory their EWS dependencies and move to the recommended replacement—the Microsoft Graph REST API. Administrators who ignore this will face broken email clients, failed third-party integrations, and stalled business processes.

What Changed (And Why Now)

Microsoft has been signaling the end of EWS for years, but previous announcements lacked enforceable dates. The company first recommended moving to Graph in 2018, and in 2022 it stopped adding new features to EWS. What’s new is the hard stop: the October 2026 and April 2027 deadlines are now official, with technical enforcement mechanisms like the EWSAllowedAppIds policy and automatic block behavior.

The retirement is part of a broader strategy to consolidate Exchange Online development on Microsoft Graph, which offers a modern RESTful interface, more granular permissions, and better support for emerging authentication standards. EWS, built on older SOAP and XML technology, increasingly struggles to keep pace with cloud-scale security requirements. Microsoft also cites a desire to reduce the attack surface and simplify compliance for its own engineering teams.

What It Means for You

For IT Administrators

The practical impact is immediate: every application or script that authenticates to Exchange Online using EWS must be identified, assessed, and migrated. This includes:

  • Third-party email clients like Thunderbird (via ExQuilla), older versions of Apple Mail, and Android email apps that still use EWS rather than Microsoft Graph or IMAP.
  • CRM and ERP integrations that sync contacts, calendars, or tasks via EWS.
  • Compliance and eDiscovery tools that rely on EWS to search and export mailbox data.
  • Legacy mobile device management (MDM) solutions that push email profiles via EWS.
  • Custom PowerShell scripts that use the EWS Managed API or raw SOAP calls.

After the disablement dates, any of these will stop working entirely unless reconfigured. Microsoft will not grant indefinite exceptions; temporary exemptions are available only until April 2027, and only for tenants that can demonstrate active migration progress.

For End Users

Most end users will not notice a thing—if their IT teams act now. Modern email clients (Outlook on Windows, Mac, iOS, Android, and the web) already use Graph or Microsoft’s own MAPI-over-HTTP protocol, so they are unaffected. Disruption will surface only when IT fails to update custom or third-party tools that users depend on. Prepare for a spike in help-desk tickets in late 2026 and early 2027 if migrations are delayed.

For Developers

Developers who have built internal apps or integrated EWS into their software products face a hard rewrite. The EWS Managed API and the SOAP endpoints https://outlook.office365.com/EWS/Exchange.asmx will go dark. The recommended path is to use the Microsoft Graph SDKs or direct REST calls. Microsoft offers a migration guide and a Graph-to-EWS mapping tool, but the complexity varies widely by feature. Public folder access, for example, lacks a one-to-one Graph equivalent, requiring workarounds.

How We Got Here

EWS was introduced with Exchange Server 2007 as a comprehensive SOAP API, intended to replace a patchwork of earlier protocols (WebDAV, CDO, MAPI). For over a decade, it was the primary method for external access to Exchange data. Even after Microsoft introduced the REST-based Outlook REST API in 2015, EWS remained the only fully-featured option for many scenarios.

The shift toward Graph began in earnest in 2018, when Microsoft started encouraging developers to use Graph for new projects. In 2022, the company announced it would no longer invest in EWS feature development. That same year, it introduced the EWSAllowedAppIds tenant-level setting, allowing admins to explicitly list which applications could use EWS—essentially creating a soft-off switch. The latest announcement turns that switch into a mandatory, time-bound enforcement.

What to Do Now

Step 1: Audit Your EWS Usage

Turn on mailbox audit logging and analyze the EWSApplicationAccess entries. Microsoft’s Purview compliance portal can surface which applications and users are making EWS calls. Third-party tools like Quest Migration Manager or native PowerShell scripts can also help.

# Example: Search audit log for EWS access in last 90 days
Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-90) -EndDate (Get-Date) -Operations EWSApplicationAccess -ResultSize 1000

Don’t forget to check for hard-coded credentials or application impersonation accounts that might not appear in typical user-activity logs.

Step 2: Triage Based on Business Impact

Classify each EWS-dependent application:
- Critical, no Graph alternative yet: Contact the vendor immediately. If in-house, begin a Graph migration project. Microsoft has published a detailed mapping guide that aligns EWS operations to Graph endpoints.
- Replaceable with native Graph capability: Schedule the migration for the next release cycle. Many modern SaaS tools already offer a Graph connector.
- Low priority, can be retired: Decommission before October 2026.

Step 3: Enforce the Allowed App List

Proactively configure the EWSAllowedAppIds policy to explicitly list applications you intend to keep using until migration. This creates a “safe list” and immediately blocks anything else, giving you a real-world test of what will break. Set the policy in the Exchange admin center under Organization > Add-ins > Exchange Web Services allowed app IDs. Or use PowerShell:

Set-OrganizationConfig -EWSAllowList "app1-client-id","app2-client-id"
Set-OrganizationConfig -EWSEnabled $false # This will require the allowlist for any EWS access

Step 4: Train Your Staff and Communicate

Ensure your help desk knows that EWS-related issues will increase. Inform end users that legacy email clients may require updates or replacements. For developers, schedule internal workshops on Graph fundamentals.

Step 5: Request an Exemption Only If Necessary

If you have a large, complex migration that absolutely cannot finish by October 2026, Microsoft will accept exemption requests through the standard support channel starting in early 2026. Exemptions are temporary—they expire no later than April 2027—and require proof of an active migration project. Do not bank on an exemption; use it only as a safety net.

Outlook

Between now and April 2027, expect Microsoft to increase pressure on tenants that still use EWS heavily. The Message Center will issue reminders, and the compliance dashboard may show “Service Health” advisories. The Graph ecosystem will also mature: look for improved public folder support, granular licensing-aware APIs, and better documentation for legacy EWS patterns. The window is generous for a reason—organizations that start planning today will have ample time to migrate without disruption. Those that delay risk scrambling through a forced migration under a hard deadline.