EWS Retirement: An SMB Microsoft 365 Migration Plan

Exchange Web Services can be buried inside a backup job, an archive connector, a public-folder workflow, an old scheduling application, or a script that nobody has touched in years. That is why Microsoft's retirement of EWS in Exchange Online is an operations project, not just an API change.

Microsoft's current retirement plan applies to Exchange Online. EWS for on-premises Exchange Server mailboxes is not being retired, but hybrid dependencies still need review because calls from an on-premises component to a cloud mailbox are in scope. Microsoft has also stated that there will be no extension beyond April 1, 2027. See the Exchange Team's current retirement timeline and the Microsoft Learn retirement roadmap.

Why SMB leaders should treat EWS retirement as a business continuity issue

EWS is a mailbox access interface. An integration can use it to read or write messages, calendar items, contacts, folders, attachments, permissions, or other Exchange data. When that interface is disabled, Exchange Online itself may remain healthy while the dependent workflow silently stops.

The visible symptom may appear somewhere else: backups stop capturing new items, an archive search becomes incomplete, a public folder no longer receives processed content, a line-of-business system stops creating appointments, or a hybrid user loses a coexistence feature. The business owner may see the break before the Microsoft 365 administrator does.

This is why an EWS migration register needs both technical and business ownership. “The vendor says it supports Graph” is not enough. A business leader needs to know which specific function was migrated, whether historical and special mailbox types remain covered, what changed in permissions, how failure will be detected, and who can approve a temporary exception.

The dates and decisions that matter

The end-of-August milestone is valuable because it leaves time for controlled testing. It also prevents a usage-based list from becoming an unreviewed catalog of everything that happened to call EWS. Infrequent applications can still be missed: Microsoft's EWS usage report covers 7, 30, or 90 days and aggregates activity weekly. A quarterly process, year-end archive job, disaster-only recovery process, or dormant integration might not appear.

Build an EWS dependency register, not just an application list

Start with the Microsoft 365 admin center EWS usage report. It identifies application IDs, SOAP actions, call volume, and last activity. Then correlate that evidence with Microsoft Entra app registrations and enterprise applications, Exchange Online RBAC assignments, sign-in logs, audit records, configuration files, job schedulers, service accounts, vendor consoles, and business-owner interviews. Microsoft's EWS discovery guidance describes how its reporting script adds identity and operational context to the admin center signal.

Search code and configuration for indicators such as the Exchange Online EWS endpoint, EWS Managed API libraries, EWS.AccessAsUser.All, full_access_as_app, impersonation roles, and application policies. Do not stop when the known app registrations are accounted for. A delegated desktop tool or service-account workflow can be owned outside the Microsoft 365 team.

For every row, record the business process, technical owner, business owner, vendor, product version, application ID, identities used, target mailboxes, EWS operations, peak and infrequent schedules, replacement design, required permissions, pilot group, rollback, exception expiry, and final retirement date. An application is not closed merely because calls disappear; it is closed when the business process has a verified supported path or has been formally retired.

Understand EWSAllowedAppIDs and EWSEnabled before changing either

EWSAllowedAppIDs is a tenant-level list of application IDs permitted to use EWS when the organization has EWSEnabled=True. It is different from the older user-agent allow and block lists. Microsoft's EWSAllowedAppIDs guidance is the authoritative reference for the retirement behavior.

• EWSEnabled=False: EWS is blocked for the organization; the organization setting overrides per-user EWS exceptions.
• EWSEnabled=True with a populated list: only the listed application IDs can use EWS.
• EWSEnabled=True with an empty list after enforcement starts: EWS is effectively blocked.
• EWSEnabled=Null: EWS remains broadly allowed only until Microsoft's phased process changes the tenant to False. The allow list is ignored while the value is Null.

Microsoft documents separate user-level controls through Set-CASMailbox, but an organization-level block disables those overrides. Before any change, export the organization and relevant mailbox settings, preserve the current full application-ID list, and verify the intended outcome. Writing EWSAllowedAppIDs replaces the full list; it is not a single-item append. Microsoft also says list changes can take up to 24 hours to take effect. Review the current EWS access-control documentation before execution.

Cross-tenant Free/Busy, MailTips, Calendar Sharing, and Exchange hybrid features have separate Microsoft transition guidance. Do not assume an application allow list controls every organization-relationship or hybrid call. Record those dependencies as their own workstreams.

Require evidence from every vendor

Ask each vendor for a written, product-version-specific answer. “We support Microsoft 365” or “we are Graph ready” is too broad. A backup connector can use Graph for primary mailboxes while retaining a gap for archive mailboxes or public folders. An archive product may support new ingestion but not the same historical export path. A scheduling product may require different permissions for shared mailboxes or room calendars.

1. Which installed versions still call EWS, and which exact release removes that dependency?
2. Which functions move to Microsoft Graph, and which use another Microsoft-supported interface?
3. Are primary mailboxes, shared mailboxes, online archives, public folders, Microsoft 365 Groups, calendars, contacts, attachments, and delegated folders all covered?
4. Which delegated or application permissions are required, and can access be limited to the intended mailboxes?
5. Does the connector create a new Entra application or reuse an existing one? Who owns certificates or secrets and their rotation?
6. How does the product handle throttling, missed notifications, subscription renewal, paging, retries, and partial failures?
7. Will the first Graph job be full, incremental, or a new backup chain? Does retention or deduplication change?
8. What monitoring proves success, and which failure alerts reach the customer rather than only the vendor?
9. What is the supported rollback before April 1, 2027, and what becomes impossible after that date?
10. What support case, release note, test evidence, and target date back the answer?

Microsoft openly lists remaining Graph parity gaps, including public-folder import/export and in-place archive scenarios. The ordinary Outlook mail API also does not access in-place archive mailboxes. That does not mean every affected product will fail; a vendor may use another supported design. It does mean the vendor must prove the exact coverage instead of relying on a generic Graph statement.

Plan the permission migration as a security change

EWS and Graph both support delegated and application access, but the models are not equivalent. EWS app-only access has historically been broad, and EWS impersonation often relies on a mailbox service account. Microsoft Graph uses an application identity for unattended access and offers permissions separated by workload, such as mail, calendar, contacts, and sending. Microsoft's authentication comparison explains the difference.

Build the new grant from the operations the application actually needs. A read-only archive collector should not receive send rights because a legacy EWS permission happened to include them. A room-calendar tool should not automatically receive tenant-wide mail access. Record who approved admin consent, the exact application and service-principal object IDs, certificate or secret expiry, mailbox scope, and the test used to prove the scope.

For app-only Exchange Online access, evaluate RBAC for Applications, Microsoft's replacement for Application Access Policies. One important trap is additive permissions: if the same app retains an unscoped Graph permission in Microsoft Entra ID, a resource-scoped Exchange RBAC grant does not narrow that separate grant. Test both a mailbox that should be accessible and one that should be denied.

Handle hybrid and public-folder dependencies as special cases

Pure on-premises Exchange Server EWS is outside this retirement, but that does not make a hybrid organization safe. Identify the caller, target mailbox, direction, and feature. An on-premises server calling Exchange Online for rich coexistence is a cloud EWS dependency even if the server itself remains on premises.

Microsoft now uses a dedicated Entra application for Exchange hybrid communication. Its current hybrid application guidance says Exchange Server Subscription Edition with the May 2026 update supports Graph for most rich-coexistence scenarios, but not every feature or cloud is supported. Inventory Free/Busy, MailTips, profile photos, archive moves, organization relationships, and any third-party app that uses Autodiscover to choose a mailbox endpoint.

Public folders deserve a separate owner because they often function as shared queues, historical archives, or application stores rather than ordinary collaboration folders. Map mail-enabled public folders, automated item movement, custom permissions, and import/export. If the Graph replacement does not cover the exact workflow, decide whether to redesign it around a shared mailbox, Microsoft 365 Group, SharePoint, another supported platform, or a vendor service. Do not perform that redesign during the final cutover window.

Prove backup and archive coverage with restores

A green connection status only proves authentication and a successful API handshake. It does not prove that every required object is protected or recoverable. After a vendor changes its connector, compare pre- and post-migration coverage and run an actual restore.

• Protect and restore a current message with attachments and metadata.
• Restore a calendar event, recurrence, attendee list, and cancellation behavior.
• Validate contacts and any application-specific extended properties.
• Test primary and shared mailboxes, delegated folders, and every licensed archive feature.
• Test a public-folder sample when that workload is claimed as supported.
• Confirm deleted-item, point-in-time, retention, search, export, and legal-workflow requirements.
• Compare expected item counts or governed samples without exposing mailbox content.
• Verify alerting for throttling, expired credentials, consent removal, partial jobs, and missed change notifications.

Graph clients must expect throttling and honor the Retry-After response. Microsoft recommends change tracking or notifications rather than continuous polling where supported. Test the vendor or custom integration under representative volume, because a successful small pilot does not prove a full backup window will complete.

Use a pilot that represents the hard cases

Use a separate test tenant with synthetic information when the product and licensing model allow it. A test tenant protects production mail and gives the team freedom to test denied permissions, expired credentials, API failures, and rollback. It may not reproduce every production condition, so document differences in licensing, public folders, archives, hybrid topology, mailbox size, and third-party connections.

If a separate tenant cannot represent the workflow, use a tightly scoped production pilot approved by the business owner. Include at least one ordinary user mailbox, shared mailbox, delegated workflow, room or calendar case, archive or public-folder case where relevant, and a mailbox that the app must be unable to access.

The pilot exit criteria should include:

• all required business actions complete successfully;
• forbidden mailboxes and operations are denied;
• monitoring detects simulated authentication and workload failures;
• backup and archive products complete both collection and restore tests;
• performance and throttling remain within the business window;
• old credentials and permissions have a scheduled removal step; and
• the business owner accepts the user-visible changes.

Design rollback and temporary exceptions before cutover

A useful rollback is specific and time-bounded. Preserve the previous connector version when supported, export configuration, record old and new app identities, define the maximum outage the business accepts, and name the decision maker who can invoke rollback. Test rollback before the broad rollout, not after a failed migration.

Before April 1, 2027, a narrowly populated EWSAllowedAppIDs list with EWSEnabled=True can keep an approved dependency running while its migration finishes. Each exception should include:

• business process and accountable owner;
• application ID, vendor, version, and target mailboxes;
• justification and least-privilege controls;
• monitoring and incident response contact;
• migration milestone and weekly progress review;
• an expiration date well before April 1, 2027; and
• a shutdown decision if the vendor cannot deliver.

Do not call this an extension. It is a temporary continuity control inside Microsoft's phased window. A rollback to EWS is impossible after the final shutdown, so late projects need an alternative business process, not a promise to re-enable the protocol.

Sequence the migration without creating a second outage

1. Discover: establish the 90-day usage baseline, find permissions and identities, search code and configuration, and interview owners.
2. Classify: retire unused apps, migrate supported apps, redesign parity-gap workflows, and approve only bounded temporary exceptions.
3. Prepare: update products, create app identities, grant scoped permissions, configure monitoring, and document rollback.
4. Pilot: validate functional, negative-access, performance, backup, restore, and alerting outcomes.
5. Deploy in waves: move lower-risk dependencies first, then shared and business-critical systems with owner coverage.
6. Observe: compare reports, sign-ins, job success, restore tests, and help-desk signals through a defined stability window.
7. Remove: revoke obsolete EWS permissions, service-account access, secrets, certificates, and app registrations only after proof and rollback expiry.
8. Recheck: rerun EWS reporting until expected usage is zero and investigate every remaining application ID.

Keep the backup and disaster recovery owner involved when connector behavior or coverage changes. For organizations that need help resolving Microsoft 365 identities, permissions, hybrid dependencies, and vendor cutovers, ITECS provides Microsoft 365 consulting and can coordinate the plan with the broader managed IT service owner.

Communicate in business language

Each application owner should receive a short notice that answers five questions: what process is affected, what users or records are in scope, what will change, when testing and cutover occur, and what to do if the process fails. For a backup or archive tool, explain the protection and restore implications. For a scheduling or CRM integration, explain the user-visible workflow. For hybrid features, tell the help desk which Free/Busy or MailTips symptoms to recognize.

Leadership should receive a weekly exception register through final migration. The useful measures are not the number of meetings held or vendors contacted. Track:

• active EWS application IDs and call volume;
• dependencies with verified business and technical owners;
• migrated, retired, redesigned, and exception workloads;
• permissions reduced or removed;
• successful backup and restore coverage by workload;
• pilot failures and unresolved parity gaps;
• exceptions without a vendor-supported exit; and
• days remaining to the internal cutoff and April 1, 2027.

The SMB EWS retirement checklist

• Export the 90-day EWS usage report and record that it is weekly aggregated.
• Review Message Center notices, Entra apps, service principals, API permissions, Exchange RBAC, sign-ins, audit records, scripts, and endpoints.
• Inventory backup, archive, public-folder, hybrid, line-of-business, script, and service-account dependencies.
• Name a business owner and technical owner for every dependency.
• Record application IDs and verify the full EWSAllowedAppIDs value before any write.
• Choose an intentional EWSEnabled state; do not leave Null as a strategy.
• Obtain product-version-specific vendor evidence and Graph or replacement dates.
• Map EWS operations to supported APIs and redesign parity-gap workflows early.
• Replace service-account impersonation with governed app identities where applicable.
• Apply least privilege and test both permitted and denied mailboxes.
• Validate backup, archive, shared-mailbox, archive-mailbox, public-folder, and restore coverage as applicable.
• Pilot with representative workloads, failure injection, monitoring, and rollback.
• Give every temporary exception an owner, expiration, and exit plan.
• Recheck EWS usage until only approved temporary traffic remains, then drive it to zero.
• Complete the permanent migration before April 1, 2027.

Methodology and update note

This article was researched from Microsoft Exchange Team and Microsoft Learn sources current on August 20, 2026. It distinguishes Microsoft's published platform behavior from ITECS operational recommendations. Graph feature parity and the phased enforcement process may change, so administrators should review the linked Microsoft sources and their tenant Message Center before making production changes. This is operational planning guidance, not a guarantee of vendor feature coverage or a substitute for tenant-specific testing.