EWS Retirement 2026: Impact on Microsoft 365 & Microsoft Graph Migration Details

If your organization uses Microsoft 365, Exchange Online, third-party email integrations, or custom applications, one of Microsoft's most important Exchange technology transitions is approaching.

Exchange Web Services (EWS) has been used for years by applications to interact with Exchange mailboxes. But EWS is a legacy technology, and Microsoft is moving Exchange Online integrations toward modern alternatives, particularly Microsoft Graph.

Microsoft stopped investing in new EWS functionality for Exchange Online years ago. The company has now reached the retirement stage, with significant changes beginning in October 2026.

For Microsoft 365 administrators, developers and IT leaders, the message is simple:

Let's understand exactly what's changing, who will be affected, what replaces EWS, and what Microsoft 365 administrators should be doing right now.

What Is Exchange Web Services (EWS)?

Exchange Web Services, commonly known as EWS, is an API that applications can use to communicate with Exchange.

It has existed since the Exchange Server 2007 era and has been extensively used by enterprise applications, custom applications, migration solutions and integrations that need access to Exchange mailbox data.

Depending on the application and implementation, EWS can be involved in operations relating to:

• Email messages
• Mailbox folders
• Calendars
• Meetings
• Contacts
• Mailbox items
• Delegation
• Enterprise applications
• Third-party integrations
• Custom automation

EWS uses a SOAP-based architecture. Microsoft Graph, by comparison, provides modern REST-based APIs and uses JSON, alongside modern authentication and authorization models.

Is Microsoft Discontinuing EWS?

Yes, but there is an important distinction.

You may see October 1, 2026 described as the "EWS end-of-life date." That description can be misleading.

Microsoft announced back in 2018 that EWS for Exchange Online would no longer receive functionality updates. In 2023, Microsoft announced its plan to disable EWS in Exchange Online beginning in October 2026.

The retirement is now being handled as a phased process.

Important EWS Retirement Dates

• October 1, 2026: Major EWS retirement/disablement measures begin in Exchange Online.
• October 2026 to March 2027: EWS retirement transition period.
• April 1, 2027: EWS requests to Exchange Online are permanently blocked.

Microsoft's current guidance for affected hybrid Skype for Business Server scenarios, for example, specifically states that after April 1, 2027, all EWS requests to Exchange Online will be permanently blocked.

Therefore, organizations should not interpret October 1 as an additional six months in which they can safely postpone their migration.

What Microsoft 365 Services Are Affected?

The most important thing to understand is that this retirement specifically concerns EWS in Exchange Online.

It does not mean that Microsoft 365 itself is being retired, and it does not mean Outlook will suddenly stop providing email service to every Microsoft 365 user.

Instead, the primary risk is associated with applications and services that depend on EWS to communicate with Exchange Online.

Microsoft has also been removing EWS dependencies from its own products. Its EWS retirement documentation references work across products including Microsoft Outlook, Office, Teams and Dynamics 365.

How Will EWS Retirement Impact Microsoft 365 Users?

For most normal Microsoft 365 users, the retirement is likely to be largely invisible.

An employee who simply opens Outlook to send and receive emails shouldn't assume that Outlook will stop working on October 1.

The bigger problem exists behind the scenes.

An organization might have an application that has been accessing Exchange Online via EWS for years without its users even knowing about it.

For example, organizations need to review:

• Third-party email integrations
• Calendar applications
• Scheduling solutions
• Custom business applications
• Legacy Microsoft 365 integrations
• Mailbox automation
• Internal scripts
• Archiving or migration solutions
• Enterprise workflow applications

If an application requires EWS and isn't migrated or otherwise properly addressed during the retirement process, the Exchange Online functionality provided by that integration could eventually stop working.

The Biggest Challenge: Do You Know Who Is Still Using EWS?

This may actually be the most difficult part of the EWS retirement project.

Large organizations may have hundreds or even thousands of applications. Some were developed internally. Others were deployed by vendors many years ago. And the current Microsoft 365 or Exchange Online administrator may not have been around when they were originally implemented.

Fortunately, Microsoft provides an EWS Usage Report within the Microsoft 365 admin center.

Administrators can navigate to:

The report provides information such as:

• Application ID
• EWS SOAP action being executed
• Call volume
• Last activity date
• Active application information

The EWS Usage Report can be filtered over the last 7, 30 or 90 days, and its data can be exported as a CSV file for further investigation. Microsoft notes that usage data is collected and aggregated weekly and can take up to 10 days to appear.

This is an excellent starting point for an organization's EWS discovery exercise.

What Is Replacing EWS?

For a large number of scenarios, the answer is:

Microsoft recommends migrating applications that access Exchange Online using EWS to Microsoft Graph.

Microsoft Graph provides a unified API platform that applications can use to interact with data and services across Microsoft 365.

From an Exchange integration perspective, Graph can provide APIs for scenarios involving areas such as:

• Mail
• Calendars
• Contacts
• Users
• Microsoft 365 groups
• Various mailbox operations

Why Microsoft Graph?

Microsoft describes Graph as providing improvements over EWS in three major areas:

1. Security

Microsoft Graph supports OAuth and granular permission scopes, helping applications limit the data they can access rather than relying on broader access patterns associated with legacy integrations.

2. Developer Experience

Developers can use Microsoft Graph Explorer, SDKs for different programming languages and Microsoft's broader Graph development ecosystem.

3. REST-Based Architecture

EWS is SOAP-based, whereas Microsoft Graph APIs are REST-based. Microsoft highlights advantages including JSON serialization and reduced network usage.

Is Microsoft Graph a 100% Replacement for EWS?

This question needs a more nuanced answer.

Microsoft Graph is the primary strategic migration destination for many EWS workloads, but administrators should not assume that every EWS feature has an identical Graph equivalent.

Microsoft maintains an EWS parity-gap roadmap and has been developing additional coverage for specific scenarios. The roadmap includes areas such as archive operations, public folders, Microsoft 365 Group-related operations, In-Place Archive access and other capabilities. Availability timelines can vary.

There is also an Exchange Online Admin API for certain administrative scenarios. Microsoft describes it as a REST-based administrative surface supporting a focused set of Exchange operations, but it does not replace the complete Exchange Online PowerShell administration surface.

Therefore, migrations need to be evaluated application by application and operation by operation.

EWS vs Microsoft Graph: What's the Difference?

EWS	Microsoft Graph
Legacy Exchange API	Modern Microsoft API platform
SOAP-based	REST-based
XML-based communication	Primarily JSON
Focused on Exchange	Connects with services across Microsoft 365
No active feature investment for Exchange Online	Microsoft's strategic API platform
Being retired for Exchange Online	Recommended migration destination for many EWS applications

Microsoft highlights Graph's improved security, developer simplicity and REST efficiency as important advantages over EWS.

What Should Microsoft 365 Administrators Do Now?

With October 2026 approaching, organizations should treat EWS retirement as an active migration project.

Here is a practical approach.

Step 1: Identify EWS Applications

Start with the Microsoft 365 EWS Usage Report.

Create an inventory containing:

• Application ID
• Application name
• Application owner
• Business owner
• EWS operations used
• Call volume
• Business criticality
• Migration status
• Vendor support status

Microsoft also points customers toward its EWS Usage Reports and EWS Analyzer tooling to help organizations identify usage and prepare migrations.

Step 2: Contact Third-Party Vendors

For each third-party product appearing in your inventory, ask the vendor:

Does the current version of your product use EWS to communicate with Exchange Online?

If yes, ask:

• Does the latest version support Microsoft Graph?
• Is an application upgrade required?
• When will EWS support be removed?
• Are configuration changes required?
• Will new Microsoft Entra permissions be required?

Don't assume that installing a newer version automatically completes your migration.

Test it.

Step 3: Review Custom Applications

Custom applications require special attention because there may not be a vendor responsible for migration.

Development teams should identify all EWS calls and map their functionality against corresponding Microsoft Graph APIs.

Microsoft provides documentation specifically covering EWS-to-Microsoft Graph API mappings, and recommends that EWS applications accessing Exchange Online be migrated to Graph.

Step 4: Review Authentication and Permissions

Moving from EWS to Graph isn't simply about replacing one URL with another.

Application teams should review:

• Microsoft Entra ID application registrations
• Delegated permissions
• Application permissions
• OAuth
• Consent requirements
• Least-privilege access
• Certificate or secret management
• Application security

Microsoft specifically highlights Graph's OAuth capabilities and granular permission scoping as security advantages over EWS.

Step 5: Test Critical Business Workflows

Do not stop after confirming that an application's Graph authentication succeeds.

Run end-to-end business testing.

For example, test functions involving:

• Email retrieval
• Email sending
• Calendar access
• Calendar creation
• Attachments
• Contacts
• Mailbox permissions
• Shared mailbox scenarios
• Application-specific workflows
• Error handling and monitoring

Step 6: Monitor EWS Usage Until It Reaches Zero

After migrating an application, continue monitoring your organization's EWS Usage Report.

The objective is simple:

The Microsoft 365 EWS Usage Report provides call-volume and last-activity information that can help validate whether applications continue to call EWS.

A Suggested EWS Migration Strategy

A practical framework for organizations is:

1. Discover: Find every application using EWS.
2. Inventory: Document owners, application IDs, EWS operations and dependencies.
3. Assess: Determine whether Microsoft Graph or another supported alternative covers the required functionality.
4. Prioritize: Move business-critical and high-volume EWS applications first.
5. Migrate: Upgrade vendor applications and rewrite or refactor custom integrations.
6. Test: Validate the application's complete business process using the replacement technology.
7. Monitor: Continue monitoring Exchange Online for remaining EWS activity.

Frequently Asked Questions About EWS Retirement

Q1. Is EWS being retired?

Yes, EWS is being retired in Exchange Online. Microsoft previously stopped investing in new EWS functionality and announced plans to disable EWS in Exchange Online beginning in October 2026.

Q2. When is EWS being retired?

The major retirement process begins in October 2026, with Microsoft documentation identifying April 1, 2027 as the point after which EWS requests to Exchange Online are permanently blocked.

Q3. Will EWS stop working on October 1, 2026?

October 1, 2026 is better understood as the beginning of Microsoft's significant EWS disablement phase rather than implying every EWS connection everywhere disappears at exactly the same moment.

Organizations should nevertheless prepare before this date rather than relying on the transition period.

Q4. Will Outlook stop working after EWS retirement?

No, the retirement announcement does not mean Exchange Online email or Outlook itself is being retired.

The concern is applications and integrations relying on EWS. Microsoft has also been working to remove EWS dependencies from its own products, including Outlook, Office, Teams and Dynamics 365.

Q5. What is the replacement for EWS?

For many Exchange Online application scenarios, Microsoft recommends Microsoft Graph. Microsoft Graph provides REST-based APIs, OAuth support and granular permission scopes.

Q6. Is Microsoft Graph a complete one-to-one replacement for EWS?

Not necessarily. Many scenarios have Graph mappings, but Microsoft maintains a roadmap covering specific EWS parity gaps. Each application's EWS functionality should therefore be evaluated before migration.

Q7. How can I find applications using EWS in Microsoft 365?

Use the EWS Usage Report in the Microsoft 365 admin center:

The report can show application IDs, EWS SOAP actions, call volumes and last activity information.

Q8. Does the retirement also apply to on-premises Exchange Server?

Microsoft's migration guidance states that Microsoft Graph is not supported for Exchange on-premises, and current retirement documentation targets EWS access to Exchange Online. On-premises Exchange Server continues to support EWS.

Q9. Should we wait until 2027 to migrate?

No.

Organizations should start identifying EWS applications and migrating them now. Microsoft explicitly recommends identifying active EWS applications and beginning migration rather than waiting for final disablement.

Final Thoughts: Don't Let EWS Retirement Become an Outage

The retirement of Exchange Web Services is more than another entry in the Microsoft 365 Message Center.

For an organization with legacy applications, custom integrations and long-standing Exchange Online dependencies, it can become a business continuity concern.

The most dangerous EWS integration isn't necessarily the largest one. It's the one nobody knows exists.

Microsoft 365 administrators should therefore begin with three questions:

1. Which applications in our tenant are still calling EWS?
2. Who owns those applications?
3. What is our migration path to Microsoft Graph or another supported alternative?

Microsoft provides EWS usage reporting and analysis resources to support that process, while recommending migration of active EWS applications as soon as possible.

With October 1, 2026 arriving soon, organizations should move from simply discussing EWS retirement to actively discovering, migrating and testing their remaining dependencies.