Microsoft Has Started Retiring EWS: Check Your Email Integrations Now

Microsoft 365 email may appear to be working normally while an important business application is approaching an outage.

On October 1, 2026, Microsoft began the phased disablement of Exchange Web Services in Exchange Online. Microsoft says EWS will be permanently retired on April 1, 2027 and recommends moving EWS-based applications to Microsoft Graph.

This does not mean that every Outlook user suddenly lost access on October 1. Enforcement is being applied in phases, tenant by tenant, and Microsoft applications have been moving away from their own EWS dependencies.

The risk is less visible: a backup product, CRM connector, archive system, scheduling platform, migration utility, line-of-business application, custom script, multifunction device workflow, or meeting-room system may still communicate with Microsoft 365 through EWS.

When Exchange Online blocks that connection, the main mailbox may continue sending and receiving email while the dependent process quietly stops.

For Southwest Florida small and midsize businesses, the practical message is:

Do not wait for an application to fail. Review your Microsoft 365 EWS usage now, identify the business owner and vendor for every active application, and create a tested migration or temporary transition plan.

What is Exchange Web Services?

Exchange Web Services, usually called EWS, is an application interface that allows software to work with Exchange mailbox information.

An application may use EWS to:

• Read, create, move, or delete email
• Access calendars and appointments
• Work with contacts or tasks
• Synchronize mailbox information with another system
• Export or import mailbox items
• Access shared mailboxes or folders
• Run automated email workflows
• Perform migration, backup, archive, or discovery operations
• Display room availability or calendar information

EWS is not the same as the Outlook application, a Microsoft 365 license, or Exchange Online itself. It is one of the ways an application can communicate with Exchange Online.

Microsoft stopped adding new EWS functionality in 2018. In 2023, the company announced that EWS in Exchange Online would be disabled beginning in October 2026. Microsoft now directs developers and customers toward Microsoft Graph and other supported interfaces.

What changed on October 1, 2026?

Microsoft began phased EWS disablement across Exchange Online organizations.

The Exchange Online service description states:

• Phased disablement began October 1, 2026.
• Permanent retirement is scheduled for April 1, 2027.
• Customers should migrate EWS applications to Microsoft Graph.

Microsoft is not necessarily disabling every tenant at the same moment. Its published transition process uses the tenant-level EwsEnabled configuration and an application-ID allow list.

In simplified terms:

• A tenant with EWS explicitly blocked remains blocked.
• A tenant left at the former default state can be changed to blocked as Microsoft’s rollout reaches it.
• Organizations that temporarily need EWS can use Microsoft’s transition controls, including an application-ID allow list, while they complete migration.
• These controls do not cancel the retirement. They provide time to manage the transition before permanent shutdown.

Administrators should not change these settings casually. Enabling all EWS traffic may restore a failed integration, but it can also reopen access for unknown or unnecessary applications. A narrow, verified allow list is safer than unrestricted access, but even an allowed application still needs a migration plan.

Why a business may not know it uses EWS

Most owners and employees never select EWS directly.

The dependency may have been introduced by:

• A software vendor
• A former IT provider
• A Microsoft 365 migration project
• A CRM or accounting integration
• A backup or archiving service
• A custom application written years ago
• An old Outlook or Mac application
• A room-booking or Teams device
• An on-premises Exchange hybrid configuration
• A consultant’s script or automation

The application may be working in the background with an identity that employees do not recognize. Its name in a Microsoft report may be an application ID rather than the commercial product name shown on an invoice.

This creates a vendor-accountability problem. The Microsoft 365 administrator may see EWS activity but not know which department bought the application. The vendor may know its product uses EWS but may not control the tenant. The business owner may assume the IT provider is managing the change even though the application belongs to another consultant.

Which organizations should be concerned?

Every Exchange Online tenant should check for active EWS use. The risk is higher for organizations with:

• Third-party Microsoft 365 backup or archive products
• CRM, practice-management, property-management, or case-management integrations
• Automated mailbox processing
• Scheduling and appointment platforms
• Shared-mailbox workflows
• Email journaling or compliance systems
• Custom scripts or internally developed applications
• Legacy migration or synchronization tools
• Exchange hybrid deployments
• Teams panels, Teams phones, or meeting-room devices
• Multiple technology vendors
• Applications that have not been upgraded recently
• Limited documentation of Microsoft 365 integrations

Medical offices, insurance agencies, law firms, property managers, nonprofits, construction companies, restaurants, franchise operators, and local governments often depend on email-driven workflows that were configured by a vendor and then left running for years.

The business impact may not appear as “email is down.” It may appear as:

• Customer messages missing from a CRM
• Appointments no longer synchronizing
• Shared-mailbox tickets not being created
• Backup jobs failing
• Archive or compliance capture stopping
• Automated approvals or notifications not running
• Room calendars appearing unavailable
• A migration project stalling
• Reports containing incomplete mailbox data

Microsoft’s own products and devices also need attention

Microsoft has been removing EWS dependencies from products including Outlook, Office, Teams, and Dynamics 365.

However, an organization should still verify versions and configuration.

Microsoft’s Teams device release notes warn that certain older Teams panel and Teams phone software falls back to EWS for calendar access. Microsoft instructs administrators to update those devices to the specified app versions or later so their calendars continue to work.

This is an important reminder: buying a Microsoft-branded service does not eliminate lifecycle work. Devices, connectors, hybrid configurations, and older clients may still require an update or redesign.

A practical EWS retirement plan

1. Review the Microsoft 365 EWS usage report

Microsoft provides an EWS Usage Report in the Microsoft 365 admin center.

Use it to identify recent EWS activity and record:

• Application ID
• Operation or activity type
• Usage dates
• Affected users or mailboxes when available
• Volume and frequency
• Whether activity is continuing

Do not assume that an unfamiliar application ID is malicious or unnecessary. Research it through Entra application registrations, enterprise applications, sign-in logs, audit records, vendor documentation, and internal ownership records.

Microsoft also provides an EWS usage-reporting tool for deeper investigation. The correct tool depends on the tenant and reporting need.

2. Build an application ownership register

For each active EWS application, document:

• Commercial product or internal application name
• Application ID
• Vendor and support contact
• Business owner
• Technical owner
• Users and mailboxes affected
• Data accessed
• Permissions granted
• Business process supported
• Current authentication method
• Current EWS operations
• Upgrade or migration status
• Contract and renewal date
• Replacement option
• Temporary exception owner and expiration date

If no one can identify the application, treat that as a security and continuity gap requiring investigation.

3. Contact vendors with evidence

Ask each vendor:

1. Does the current installed or subscribed version use Exchange Web Services?
2. What application ID should appear in our tenant?
3. Is a Microsoft Graph-based version available?
4. Which product version contains the replacement?
5. Does migration require new consent or permissions?
6. Are any EWS capabilities not yet supported in the replacement?
7. What testing is required?
8. What is the vendor’s supported deadline?
9. Is a temporary EWS allow-list entry required?
10. What rollback and support procedures apply?

Request written answers. A statement that the product “supports Microsoft 365” does not prove that its EWS dependency has been removed.

4. Classify the business impact

Not every application deserves the same priority.

Classify each dependency by:

• Criticality of the business process
• Number of users or locations affected
• Sensitivity of accessible mailbox data
• Recovery-time requirement
• Manual workaround availability
• Regulatory, contractual, or retention obligations
• Vendor readiness
• Technical migration difficulty

A calendar convenience and a medical-office message-ingestion workflow may both use EWS, but their interruption consequences are different.

5. Migrate to a supported alternative

For many scenarios, Microsoft Graph is the intended replacement.

Migration may require more than replacing a URL. Developers may need to redesign:

• Authentication and token handling
• Application permissions
• Delegated versus application access
• Mailbox scoping
• Throttling and retry behavior
• Webhooks or change notifications
• Pagination and batching
• Import or export behavior
• Archive, public-folder, or group-mailbox workflows
• Audit and error handling

Microsoft publishes EWS-to-Graph mappings, an EWS Analyzer tool, migration guidance, and an AI-assisted code-analysis and refactoring tutorial. Some specialized EWS capabilities have required additional Graph or Exchange administrative interfaces, so developers must verify feature parity for the exact workflow.

6. Use transition settings narrowly

If a critical application cannot migrate immediately, qualified administrators may use Microsoft’s transition controls to permit specific application IDs temporarily.

This should be treated as a controlled exception, not a completed remediation.

For every exception:

• Verify the application ID with the vendor
• Confirm the minimum required mailboxes and permissions
• Record the business justification
• Assign an owner
• Set an expiration date
• Monitor usage and failures
• Maintain a migration milestone
• Review the exception regularly

Avoid reopening unrestricted EWS access merely because one application failed. That may restore service quickly but can also allow forgotten applications to continue operating without review.

7. Test before and after migration

Testing should verify the business outcome, not only a successful login.

Depending on the application, test:

• Sending and receiving
• Folder access
• Shared mailboxes
• Calendar creation and updates
• Recurring appointments
• Attachments
• Contacts and tasks
• Archive mailboxes
• Impersonation or delegated access
• High-volume processing
• Backup and restore
• Error reporting
• Permission boundaries
• Failover and recovery

Use representative users and data. Do not grant broad production access to an untested replacement.

8. Monitor for silent failures

Some applications may retry quietly or stop processing without notifying a business owner.

Monitor:

• EWS error rates
• Application sign-ins
• Failed backup or archive jobs
• Missing CRM activities
• Calendar synchronization delays
• Ticket or workflow volumes
• Vendor service alerts
• User reports of missing information

Establish an escalation path so a synchronization failure is treated as a business interruption, not merely an isolated software warning.

Business-continuity planning

Before changing EWS settings or migrating an integration, identify how work will continue if the application fails.

A continuity plan should answer:

• How will customer email be monitored if the CRM connector stops?
• How will appointments be confirmed if calendar synchronization fails?
• How will the business verify that backups remain complete?
• How will compliance or archive capture be validated?
• Can employees use the mailbox directly during an outage?
• Who can authorize a temporary exception?
• Who contacts the vendor and Microsoft 365 administrator?
• What is the maximum acceptable interruption?
• How will missed transactions be reconciled after restoration?

For hurricane-prone Southwest Florida organizations, technology changes should also account for reduced staffing, internet outages, remote work, and reliance on mobile devices. Avoid scheduling a high-risk migration during a period when technical or business owners are unavailable.

Security improvements should accompany migration

EWS retirement is not only a compatibility project.

It is an opportunity to review whether each application should still have access to business mailboxes.

Ask:

• Does the application still have a legitimate purpose?
• Are its permissions broader than necessary?
• Does it have access to every mailbox when it needs only a few?
• Is application consent documented and approved?
• Are secrets or certificates protected and rotated?
• Are inactive service principals removed?
• Can administrators see and investigate the application’s activity?
• Is the vendor still supported and trustworthy?

Do not reproduce an old, overly broad EWS permission model in Microsoft Graph without review.

How AI can help

AI-assisted development and security tools can help qualified personnel:

• Explain legacy EWS code
• Map EWS operations to Microsoft Graph alternatives
• Identify authentication and permission changes
• Draft refactoring plans
• Generate initial Graph code for developer review
• Compare old and new workflows
• Summarize EWS usage and sign-in records
• Group unknown application IDs for investigation
• Identify likely owners from documentation and tickets
• Create test cases
• Analyze migration errors
• Draft user and vendor communications
• Build a dependency and risk register

Microsoft specifically references an AI-assisted EWS migration tutorial for code analysis and refactoring.

AI-generated code should not be placed directly into production. Developers must validate authentication, authorization, mailbox scoping, data handling, error behavior, rate limits, and functional parity.

Do not submit mailbox data, access tokens, application secrets, source code containing credentials, or confidential logs to an unapproved public AI service.

Where human judgment is required

Qualified people must decide:

• Which application IDs are legitimate
• Which business processes are critical
• Whether a temporary EWS exception is justified
• Which permissions the replacement requires
• Whether Microsoft Graph provides adequate functional parity
• How migration should be tested
• Whether a failed integration creates a legal or compliance issue
• When to disable an old application
• How to handle incomplete backups or missed transactions
• Whether the business can safely roll back
• Who accepts the residual risk before permanent retirement

AI can accelerate analysis and code conversion. It cannot approve mailbox access, validate a vendor’s contractual obligations, or accept the business consequences of an outage.

Questions to ask your IT provider or software vendor

1. Does our Microsoft 365 tenant show active EWS usage?
2. Can you identify every application ID in the report?
3. Which mailboxes and business processes depend on each application?
4. Which vendors have confirmed migration to Microsoft Graph?
5. Are any applications temporarily allow-listed?
6. Who approved each exception, and when does it expire?
7. Have Teams panels, Teams phones, and meeting-room devices been updated?
8. Does our backup product use EWS, Graph, or another supported interface?
9. Have backup and restoration been tested after any connector change?
10. Are application permissions limited to the required mailboxes and data?
11. What monitoring will detect a silent synchronization failure?
12. What manual procedure will employees use during an outage?
13. What must be completed before permanent retirement on April 1, 2027?
14. Can you provide evidence of testing and vendor confirmation?

How Managed Intelligence Advisors can help

Managed Intelligence Advisors helps Southwest Florida organizations turn Microsoft lifecycle changes into controlled business projects rather than emergency outages.

We can help:

• Review Microsoft 365 EWS usage reports
• Identify application IDs, owners, vendors, and affected mailboxes
• Map dependencies to business processes
• Assess backup, archive, CRM, scheduling, and custom integrations
• Review Teams devices and Exchange hybrid dependencies
• Coordinate vendors and internal stakeholders
• Evaluate Microsoft Graph migration readiness
• Review application consent and mailbox permissions
• Define temporary exception controls and expiration dates
• Create and execute functional test plans
• Validate backup and restore after connector changes
• Monitor for silent synchronization failures
• Build manual continuity procedures
• Use AI-assisted analysis with qualified technical validation
• Give leadership a clear risk register, migration timeline, and accountability plan

The objective is not merely to keep an old connection working for a few more months.

It is to identify every email-dependent business process, move it to a supported and appropriately secured design, and prove that the organization can continue operating when Microsoft completes the retirement.

Suggested call to action: Request an Exchange Online Integration and EWS Retirement Readiness Review from Managed Intelligence Advisors.