EWS Retirement: Your Exchange Online Graph Migration Plan

If you have skimmed coverage of the Exchange Web Services retirement in the last few weeks, you have probably picked up a deadline of end of August 2026 and a vague instruction to "configure your allowlist." That deadline is real, it comes from Microsoft, and for the overwhelming majority of tenants it is not the deadline that applies to you. Acting on the wrong one is how teams end up either panicking a month early or, worse, relaxing after the wrong milestone passes.

Here is the correction, up front. The end-of-August date is Microsoft's hard cutoff for Skype for Business Server hybrid deployments specifically, published on the Skype for Business hybrid EWS retirement page. For every other Exchange Online tenant, the documented mechanics are different: if you have not built your own allowlist before September 2026, Microsoft builds one for you from your tenant's own EWS telemetry, and the consequence lands on 1 October 2026, when EWS starts being disabled by default. The end of August is when you stop controlling the list. The start of October is when things stop working.

This article walks the timeline, shows you how to find your actual EWS callers before you make any decisions, gives the exact cmdlets, and is honest about the parts of EWS that Microsoft has stated will never reach Graph.

Two Dates, and What Each One Actually Does

EWS has been deprecated since July 2018 and its retirement was announced on 19 September 2023, so nobody can claim surprise. What changed is the scope and the enforcement. After the January 2024 Midnight Blizzard incident — in which EWS featured — Microsoft widened the retirement from third-party applications to its own first-party applications as well. That removed the last plausible "surely Microsoft will carve out an exception" argument.

1 October 2026 — disabled by default. Any tenant still sitting at the default EwsEnabled = Null gets flipped to $false. If you have explicitly set EwsEnabled = $true, EWS keeps working, but only for the App IDs present on EwsAllowedAppIDs. Everything else gets refused. This is the date that generates the support tickets.

1 April 2027 — permanent retirement. Microsoft's wording is "no exceptions." No allowlist entry, no $true, no admin override, no support ticket changes the outcome. The switch is not a policy after that date; it is an absence.

Between those two dates you have a bridge, not a reprieve. The allowlist is a mechanism for keeping a known, inventoried set of applications alive while their owners finish a Graph migration. It is not a way to defer the migration.

Find Your Callers Before You Touch Any Setting

The most common failure in this project is configuring an allowlist from memory. Almost every tenant has EWS traffic nobody in the room can name: a decade-old signature manager, a room-booking panel, a backup product's legacy connector, a departed contractor's reporting script running on a scheduled task.

Microsoft ships the answer. The EWS Usage Report lives in the Microsoft 365 admin center under Reports → Usage → Exchange, on the EWS usage tab. It offers 7, 30, and 90-day windows and gives you four columns that matter: Application ID, SOAP Action, Call Volume, and Last Activity date in UTC. You can export the whole thing to CSV, which is where the real work happens.

There is one caveat in Microsoft's documentation for the report that dictates your schedule more than any other single fact: "It can take up to 10 days for usage to show in the report." Start discovery on 30 September and the report will still be filling in when the default flip has already happened. Start it this week and the 90-day window will have caught your quarter-end batch jobs, your annual-ish reporting scripts, and the seasonal integrations that only run twice a year.

Work the CSV like an inventory, not a report:

1. Pivot on Application ID, sorted by call volume descending. The top five App IDs usually account for the great majority of traffic and are the ones with real owners.
2. Resolve each App ID in Entra ID → Enterprise Applications. A resolved display name turns "unknown GUID" into "the HR onboarding connector," which turns an unknown into a conversation.
3. Read the SOAP Action column as a requirements list. SyncFolderItems, Subscribe, GetUserAvailability and friends tell you exactly which Graph capability that caller needs — before you talk to a single vendor.
4. Treat Last Activity as your decommission evidence. An App ID that last called EWS eleven weeks ago is a candidate for simply being switched off, and the report is the artifact that lets you say so with a straight face.

A note on Entra sign-in logs, because you will see them recommended: they are a reasonable corroborating signal for confirming an App ID is still authenticating, but Microsoft publishes no EWS-specific KQL query or sign-in log column for isolating EWS traffic. Any query you find claiming otherwise is somebody's inference. Correlate the App IDs you got from the usage report against sign-in activity yourself, and treat the usage report as the authority.

For code you own, the EWS Code Analyzer is worth twenty minutes of setup. It is a Roslyn analyzer for Visual Studio and VS Code that scans .NET source for EWS calls and suggests the Graph equivalents inline, available via aka.ms/ewsTools. It will not migrate anything for you, but it converts "we think that service uses EWS somewhere" into a file-and-line list.

Discover, Decide, Migrate

flowchart TD
    N1[EWS Usage Report
90 days, by App ID] --> N2{Last Activity in window?}
    N2 -->|No| N3[Decommission
Do not allowlist]
    N2 -->|Yes| N4{You control the code?}
    N4 -->|No| N5[Vendor path
Written Graph date
Bridge on allowlist]
    N4 -->|Yes| N6{Feature in Graph?}
    N6 -->|GA| N7[Migrate to Graph
App-only + RBAC]
    N6 -->|Preview| N8[Prototype now
Bridge, then re-test]
    N6 -->|Never| N9[Redesign or retire
No allowlist saves this]

The branch that people skip is the last one. If a caller depends on something Microsoft has said will not exist in Graph, no amount of allowlist configuration helps, and the only useful move is to surface that as a business decision while there is still budget and calendar to respond to it.

The Allowlist: Exact Cmdlets and One Trap

The org-level controls live on Set-OrganizationConfig, documented on Microsoft's page for controlling access to EWS in Exchange. Start by reading your current state, because a surprising number of tenants have never set these at all:

# What is the tenant actually configured to do today?
Get-OrganizationConfig | Format-List EwsEnabled, EwsApplicationAccessPolicy

If EwsEnabled comes back empty, you are in the default state — and that default is exactly what changes. Microsoft states it plainly: "The default value Null is treated as EwsEnabled set to True." That treatment is what ends on 1 October.

To keep a controlled set of applications running through the bridge period, set the flag explicitly and populate the allowlist:

# Explicitly enable EWS at the org level
Set-OrganizationConfig -EwsEnabled:$true

# Restrict EWS to a known set of application IDs
Set-OrganizationConfig -EwsAllowedAppIDs "guid1,guid2"

The behaviour is narrower than the parameter names suggest, and Microsoft says so directly: "When EWSEnabled is set to True, only the Application IDs in this list can use EWS." Setting $true without populating the list does not mean "everything works." It means you have opted into an allowlist model with an empty allowlist. Verify the list contents after every change.

Per-mailbox overrides exist and behave the way you would expect from Exchange precedence rules:

# Per-user override — only meaningful when the org is not disabled
Set-CASMailbox -Identity user@contoso.com -EwsEnabled:$true

And here is the trap worth writing into your runbook, again in Microsoft's own words: "Disabling EWS in the organization also disables per-user EWS overrides." An org-level $false beats a mailbox-level $true, silently. If a service account's mailbox is configured for EWS and the tenant flips to disabled on 1 October, that mailbox setting becomes decoration. Nobody gets an error explaining the precedence; the calls simply stop.

One more scheduling point. If you do nothing before September, Microsoft populates an allowlist from your own tenant telemetry — an algorithmic guess based on what has been calling recently. That is better than nothing, and it is not a plan. It will happily include the abandoned contractor script and may miss the quarterly job that has not run inside the observation window. Build the list yourself from the CSV you already exported.

What Maps Cleanly to Graph

For most workloads the migration is mechanical rather than architectural. Microsoft maintains an explicit EWS to Microsoft Graph API mapping, and the well-trodden paths all have destinations:

• Mail operations — create, read, update, delete, send, move, copy.
• Folders and attachments — full CRUD, including large attachment handling.
• Inbox rules, MailTips, and Out of Office — all present.
• Calendar — availability lookups, reminders, and calendar sharing.
• Notifications — EWS pull subscriptions become Graph delta queries; EWS push Subscribe becomes Graph subscriptions with webhooks.
• Synchronisation — SyncFolderItems becomes the delta query pattern.

The notification and sync changes are the ones that require real thought rather than a search-and-replace. A pull-subscription design that polls on a timer maps onto delta queries fairly directly. A push-subscription design has to account for Graph's subscription lifecycle: subscriptions expire, renewal is your responsibility, and your webhook endpoint must respond to the validation handshake. Budget engineering time for that specific piece; budget almost none for mail CRUD.

What Will Not Make the Crossing

This is the section that decides whether your project has a nasty surprise in it. Microsoft's own mapping documentation is explicit about the gaps, and its 2023 retirement announcement conceded that "it's possible some functionality will not make it to Microsoft Graph." Treat the following as the citable list — vendor blogs and forum threads speculate well beyond it.

Permanently not migrating:

• Public folder CRUD "will not be available" in Microsoft Graph. If a line-of-business application reads or writes public folders through EWS, there is no Graph destination for it. That is a redesign or a migration off public folders entirely, and it is not a five-week piece of work.
• Creating a calendar event without inviting attendees "will not be supported in Microsoft Graph API." This one catches room-booking, resource-management, and blocking-time automations that deliberately create events with no invitees.

Preview only, not generally available:

• Mailbox import and export
• User configuration
• The newer admin APIs — accepted domain, distribution group membership, mailbox endpoints, and organisation config

Preview means you can prototype and you can validate the shape of your migration, but you should not put a compliance-critical workload behind it and call the project finished. Re-test these against GA status well before April 2027.

Roadmap items with no committed destination:

• Microsoft 365 Groups import and export
• In-place Archive access
• Event delta for recurring events
• Sticky Notes CRUD

If any of these appear in your SOAP Action column, escalate now. A dependency with no Graph equivalent and a hard April 2027 end date is a business risk, not a technical backlog item, and the people who can fund a redesign need months of notice.

Impersonation Is Gone: App-Only Access and RBAC

The EWS service-account-plus-impersonation pattern is the single most common architectural dependency in older integrations, and it has no direct replacement. Microsoft's authentication migration guidance is unambiguous: "With Microsoft Graph, there are no service accounts… The way to achieve Impersonation in Microsoft Graph is by making use of app-access policy and application permissions."

The upside is real, and it is worth putting in the business case rather than presenting this purely as forced work. Microsoft's assessment of the old model: "EWS has all or nothing access model and there is no granular scoping." Graph replaces that with per-feature application permissions, so a signature-management application can be granted mail read access to one scoped set of mailboxes instead of effective access to everything.

Now the currency point that most migration guides published before this year get wrong. New-ApplicationAccessPolicy still works, and it is still what half the internet will tell you to run. Microsoft's current guidance says otherwise: "Don't create new App Access Policies as these policies will eventually require migration to Role Based Access Control for Applications." Building your 2026 migration on App Access Policies means scheduling a second migration for yourself.

The recommended path is RBAC for Applications, which uses a different and more granular set of cmdlets:

# Register the app's service principal in Exchange Online
New-ServicePrincipal -AppId <app-guid> -ObjectId <entra-object-guid>

# Define the mailbox scope the app is allowed to touch
New-ManagementScope -Name "Signature Service Scope" `
  -RecipientRestrictionFilter "Department -eq 'Sales'"

# Grant a single scoped role, not tenant-wide access
New-ManagementRoleAssignment -Role "Application Mail.Read" `
  -App <app-guid> -CustomResourceScope "Signature Service Scope"

# Prove it before the app tries it
Test-ServicePrincipalAuthorization -Identity <app-guid>

Test-ServicePrincipalAuthorization is the step teams skip and then regret. It tells you what the service principal is actually authorised to do, in advance, rather than letting a production job discover it at three in the morning. If you are also cleaning up how these applications obtain credentials in the first place, this is a natural moment to move CI-driven jobs onto workload identity federation rather than porting client secrets across to the new model.

Skype for Business Server Hybrid: The Genuinely Different Deadline

If you still run a Skype for Business Server hybrid deployment, your date is the one everyone else has been quoting incorrectly. Microsoft's hybrid guidance sets a hard configuration deadline at the end of August 2026 for these deployments, because the on-premises servers reach into Exchange Online over EWS for free/busy, archiving, and unified contact store operations. Missing that window is a service break for an on-premises platform, not just an application outage.

That population is small and shrinking, which is exactly why the deadline generalised so badly in secondhand coverage. Confirm which category you are in before you set your project dates, and put the answer in writing where your change advisory board can see it.

The Next Five Weeks

A sequence that fits the calendar you actually have:

1. This week: export the EWS usage report at 90 days. Nothing else can be planned until you know who is calling. Remember the ten-day ingestion lag — the report you pull today describes a window that closed a week and a half ago.
2. Resolve every App ID in Entra Enterprise Applications and assign each one a named owner. Unresolvable IDs are findings, not blockers.
3. Run the EWS Code Analyzer across any in-house .NET that touches mailboxes, and cross-check the results against the report.
4. Sort each caller into four buckets using the flow above: decommission, migrate now, bridge on the allowlist, or escalate as a gap. Public folder and no-attendee-event dependencies go straight to escalate.
5. Before September: set EwsEnabled explicitly and write your own EwsAllowedAppIDs. Doing nothing hands the list to Microsoft's telemetry-based guess.
6. Rebuild authentication on RBAC for Applications, not App Access Policies, and verify each app with Test-ServicePrincipalAuthorization.
7. Remove App IDs from the allowlist as each migration lands. A shrinking list is the only honest progress metric this project has.
8. Book a checkpoint for January 2027 to re-test anything you parked on a preview API, with enough runway to react before April.

The two dates do the arguing for you. On 1 October, tenants that never looked will find out which applications were using EWS the hard way, one ticket at a time. On 1 April 2027 there is no configuration left to change. The distance between those outcomes is one CSV export and a few weeks of ownership work — and the export has a ten-day lag, so the useful version of "start now" means this week.

Related Articles

• Automating Microsoft 365 with PowerShell: The Graph SDK Way in 2026
• Microsoft 365 Reporting in 2026: Usage Reports, Graph API, and Entra Logs
• Exchange Online Message Trace vs Mail Flow Rules: Diagnosing Delivery Failures Step by Step
• Entra ID Workload Identity Federation: Eliminating Secrets in CI/CD Pipelines
• Microsoft 365 Backup and Retention: What Native Tools Cover (and What They Don't)