The Final Sprint: Completing Your EWS to Microsoft Graph Migration as EWS Is Phased Out

Correction, 3 October 2026: An earlier version of this article treated 1 October 2026 as a single enforcement deadline for EWS calls from Outlook add-ins, described the AppID allow list as an extension requested from Microsoft, and recommended Outlook authentication patterns that Microsoft has turned off or now classes as legacy. Microsoft is retiring EWS in Exchange Online in phases: the deprecation began on 1 October 2026, with app allow lists required from 10 October and tenants then switched off individually with seven days’ warning, and EWS is fully and permanently disabled from 1 April 2027. The article has been corrected throughout.

Microsoft’s retirement of Exchange Web Services (EWS) in Exchange Online is not a single switch-off date. It is a phased process: the deprecation began on 1 October 2026, from 10 October tenants that have explicitly enabled EWS must name the applications allowed to use it, tenants that never changed the setting are then switched off one at a time, and EWS is fully and permanently disabled from 1 April 2027. For Outlook add-in development teams whose migration to Microsoft Graph is incomplete, that makes the usable window shorter than it looks: an individual customer’s tenant can stop accepting your EWS calls long before April 2027. A migration begun when a customer’s tenant receives its seven-day warning will not complete in seven days. A migration begun today might.

This article is a deliberately tactical guide for teams running the EWS to Microsoft Graph migration against that phased timeline. It is the operational complement to the broader migration article we published in Q1; that article explained what the migration involves. This one is about what to ship over a sixteen-week sprint to finish it. The framing is unapologetically urgent because the operational reality is.

If your team is on track and your migration is largely complete, this article is a checklist for the long tail. If your team has not started, it is a structured response to a hard situation.

How Microsoft Is Retiring EWS in Exchange Online

The EWS deprecation has been signalled for years. Microsoft announced in 2018 that EWS would no longer receive functionality updates, and in 2023 that it would be disabled in Exchange Online in October 2026. What Microsoft has since published is a phased, admin-controllable disablement rather than a single cut-off:

• 1 October 2026: the Exchange Team announced that “the deprecation of EWS in Exchange Online starts today.”
• From 10 October 2026 (worldwide multi-tenant cloud first): a tenant that has set EWSEnabled to True must also have an AppID allow list (EWSAllowedAppIDs), and only the applications on that list can use EWS. Tenants in other clouds are to receive their own timelines through Message Center.
• Second phase: tenants that never changed EWSEnabled (it is still Null) are switched to False, which blocks EWS for every application in the tenant. Tenants are selected individually and get a seven-day warning in Message Center. Shortly before switching a tenant off, Microsoft populates its allow list from the previous 60 days of EWS usage.
• Until final deprecation: an administrator can re-enable EWS, either as True with an allow list or by setting it back to Null, though re-enabling after a block means a service interruption in between.
• 1 April 2027: EWS in Exchange Online is “fully and permanently disabled”, tenant administrators lose control of EWSEnabled, and Microsoft has said that “there will be no exceptions past April 2027.”

EWS in on-premises Exchange Server is not affected.

For Outlook add-ins there is a second, separate change that matters as much. Microsoft has turned off legacy Exchange Online user identity tokens and callback tokens across all Microsoft 365 tenants, and recommends MSAL with nested app authentication (NAA) for add-ins that need delegated access or user identity. Microsoft’s guidance on calling EWS from inside an Outlook add-in with makeEwsRequestAsync is now scoped to Exchange on-premises. We return to authentication below.

What this means in practice — and this is our reading, not Microsoft’s — is that there is no single date to plan against. For an add-in vendor, whether EWS calls succeed in a given customer’s tenant depends on that tenant’s configuration and on when Microsoft selects it, and the seven-day warning goes to that tenant’s administrators, not to you. The only date that applies to everyone is 1 April 2027. The AppID allow list is a tenant-level setting that each customer’s administrator controls, not an extension that vendors apply to Microsoft for, and it is not a substitute for migration. We address it specifically later in this article.

An add-in that no longer calls EWS is unaffected by any of these phases. One that still does is exposed in every tenant that blocks it, from the day that tenant blocks it.

The Irreducible Minimum: What Must Be Migrated

Most Outlook add-ins use EWS for a relatively small set of operations: reading mailbox properties, accessing calendar items, reading and writing mail item properties beyond what Office.js provides directly, and (less commonly) directly manipulating folders and items.

The migration translates each of these into Microsoft Graph equivalents:

Microsoft describes Microsoft Graph as having reached “near-complete feature parity for the vast majority of EWS scenarios”, and publishes a roadmap of the remaining gaps on its EWS deprecation page; it advises not to plan on any capability missing from that roadmap arriving before EWS is fully disabled. For the operations Outlook add-ins typically use, our view is that the surface is not the obstacle. There are edge cases where Graph behaviour differs from EWS in ways that require code changes (notification subscription lifecycle, time zone handling on calendar items, notification payload shape), but the obstacle is doing the migration on schedule.

The AppID Allow List: When It Is Legitimate, When It Is Dangerous

Microsoft’s AppID allow list, EWSAllowedAppIDs, is a tenant-level setting in Exchange Online. When a tenant’s EWSEnabled is True, only the applications whose App IDs appear on the list can use EWS in that tenant; once the requirement takes effect from 10 October, a missing or empty list allows no EWS at all. The customer’s administrator sets it, through Exchange Online PowerShell or Baseline Security Mode, and Microsoft says changes take 24 hours to take effect. It is not a request filed with Microsoft, and it does not extend anything beyond 1 April 2027: Microsoft has said there will be no exceptions past April 2027.

For an add-in vendor, that puts the allow list in your customers’ hands rather than yours. If your add-in’s backend still calls EWS, every customer tenant that has set EWSEnabled to True needs your application’s App ID on its list, and tenants still on the default Null are to be switched to False in Microsoft’s second phase.

In our view, relying on the allow list is legitimate in specific cases:

• Production add-ins with completed migration plans that are running into late completion. A team that has done the work but has unforeseen production issues in the final weeks may legitimately ask customers to keep its application on their allow lists as a short bridge while finishing the migration.
• Add-ins owned by third parties where the purchasing organisation does not control the migration timeline. The allow list provides interim continuity while the third party completes their work.
• Highly complex add-ins with EWS integration depth that genuinely cannot complete in the remaining window despite best efforts, including those waiting on a capability from Microsoft’s parity-gap roadmap.

The allow list is dangerous when it is treated as a substitute for migration:

• It stops mattering on 1 April 2027, when EWS in Exchange Online is disabled for everyone. That date will arrive.
• The allow list does not slow Microsoft’s EWS deprecation; it only decides which applications a tenant lets through until then.
• It depends on every customer’s administrator getting it right, in every tenant, and each tenant still running on the default setting can be switched off with seven days’ warning to its administrators.
• An organisation that uses the allow list as a planning tool — “we’ll allow-list our add-ins and migrate later” — is buying a small amount of time at the cost of compounded risk later.

Our position: if your add-in’s migration is realistically completable before your customers’ tenants block EWS, do not plan around the allow list. Migrate. If migration genuinely cannot be completed in time, treat the allow list as a bridge, with a hard-dated migration plan attached that finishes well before 1 April 2027.

A Sixteen-Week Sprint Plan

Sixteen weeks is, in our view, a realistic window for a focused migration of a typical Outlook add-in’s EWS footprint. Measured against Microsoft’s phases, the sprint has two targets: the add-in must be off EWS in each customer’s tenant before that tenant blocks it, and off EWS everywhere before 1 April 2027. The plan we recommend:

Weeks 1-2: Migration Audit and Architecture Decisions

Inventory every EWS call your add-in makes. Catalogue the operations, the contexts in which they are called, the data they return, and the downstream code that consumes the data. This is the foundation; you cannot plan without it.

For each call, decide:

• Direct migration — replace with the Graph equivalent. The default path.
• Functional change — the EWS behaviour is different from the Graph behaviour and the add-in’s behaviour will need to adjust. Document the change.
• Deprecation — the call serves a feature that can be retired. Confirm with product management.

Make architectural decisions about authentication. If your add-in already signs users in with MSAL and calls Microsoft Graph for other features, the Graph migration is largely additive. If it relies on Exchange callback or identity tokens (getCallbackTokenAsync, getUserIdentityTokenAsync), the authentication change is not optional: Microsoft has turned those legacy tokens off across Microsoft 365 tenants. If your add-in uses Exchange impersonation or app-only credentials with EWS, the migration involves authentication restructuring (typically to MSAL with Microsoft Graph delegated or application permissions).

Weeks 3-6: Core Migration Implementation

Implement the Graph equivalents for the highest-volume EWS calls. Start with the calls that are most central to the add-in’s primary value, not the ones that are easiest. The objective at the end of week 6 is that the add-in’s primary use case works against Graph end-to-end, even if some peripheral functionality is still EWS-backed.

The pattern we recommend is feature-flagged dual-path code. Wrap each EWS call site with a conditional that can call Graph or EWS based on a runtime flag. This allows:

• Easy rollback if the Graph path has issues.
• Per-environment toggling (dev uses Graph, production stays on EWS until ready).
• Per-tenant or per-user toggling for canary rollout.

The dual-path code is removed during cleanup once the migration is stable, but during the sprint it is your safety net. Bear in mind that the EWS branch only works in tenants that still let your application use EWS, and not at all after 1 April 2027; it is a rollback path, not somewhere to stay.

Weeks 7-9: Subscription and Notification Migration

Microsoft Graph subscriptions have a meaningfully different lifecycle from EWS push subscriptions. Every subscription has an expiry and must be renewed before it lapses: for Outlook messages, events and contacts the maximum lifetime is under seven days, or under one day for subscriptions that include resource data. Unless you supply a lifecycleNotificationUrl when you create the subscription (it cannot be added afterwards), you receive none of Graph’s lifecycle notifications — reauthorizationRequired, subscriptionRemoved, missed — so a lapsed subscription simply goes quiet. The notification payload shape is different — clientState validation, subscriptionId correlation, change type filtering — and your notification handlers must be updated.

This workstream is easy to underestimate late in the sprint, because the notification path is exercised in production but not always in test environments. Build the Graph subscription path in week 7, exercise it thoroughly in weeks 8 and 9, and shake out the production behaviour before week 10.

Weeks 10-12: Testing and Equivalence Validation

Validate that the migrated add-in produces equivalent results to the EWS-backed version across realistic scenarios, using tenants that still allow your application EWS access. Two patterns we recommend:

Canary tenants. Designate specific test tenants (your own dev tenants, friendly-customer test tenants) and toggle the Graph path for them. Compare add-in behaviour against EWS-backed behaviour for the same scenarios. Issues that emerge are addressed; only when the canary tenants are clean do you proceed.

Telemetry-driven equivalence validation. For high-traffic add-ins, ship code that runs both EWS and Graph calls in shadow mode (Graph in production, EWS in shadow, or vice versa) and compares results. Significant divergences are alerted. This is more invasive but produces high-fidelity confidence in equivalence at production scale.

Weeks 13-14: Production Rollout

Roll the Graph path out to production using the dual-path feature flag. Start with a small percentage of users, monitor for issues, ramp up. The deployment is not a single switch — it is a controlled increase with the option to roll back at any point if telemetry shows issues.

The critical metric is functional equivalence: the add-in must produce the same results for users on the Graph path as on the EWS path. Latency, error rate, and quality metrics must be at parity or better.

Week 15: Final Verification and Cleanup

With production stable on the Graph path, retire the EWS code paths. Remove the dual-path feature flag. Update documentation. Communicate the migration completion to internal stakeholders.

Week 16: Buffer

The final week is reserved as buffer for the unexpected. If the previous fifteen weeks ran as planned, this week is unallocated and absorbs any delays. If they did not, this week is the difference between finishing on your own schedule and finishing on Microsoft’s.

A sixteen-week sprint that compresses any of the above weeks materially increases risk. A sixteen-week sprint that has run on schedule lands with a working Graph-backed add-in, a week of buffer unspent, and no dependency on any customer’s allow list.

Accelerated Testing Strategies

Compressed-timeline migrations cannot afford the full test development cycle that a green-field migration would invest in. The strategies that produce maximum confidence with limited test development time:

Production traffic replay. Capture a sample of production EWS calls, replay them through the migrated Graph path, compare results. The capture and replay infrastructure is itself a small engineering investment, but it provides extremely high-fidelity equivalence validation.

Diff-based testing. Run the same set of test inputs through EWS and Graph paths, diff the outputs structurally. Material diffs indicate bugs; cosmetic diffs (timestamp formatting, optional fields) can be ignored systematically.

Customer canary deployment. Deploy the Graph path to a small set of customer tenants in production, with a clear rollback procedure. The signals from real production usage are higher-quality than any pre-production test set.

Telemetry-based monitoring at rollout. Increase telemetry granularity during the rollout period. Track per-call latency, error rates, and behavioural metrics with finer resolution than steady-state monitoring would normally use. Roll back on any significant deviation.

The pattern across all four is the same: accept that you cannot test exhaustively in a compressed timeline, instrument heavily so you can detect issues fast in production, and build the rollback capability that makes fast detection actionable.

Authentication Migration Specifically

Worth dedicated attention because it is where Microsoft’s platform changes bite hardest. Outlook add-ins authenticate in three common patterns:

Pattern 1: Exchange identity and callback tokens. The add-in calls getCallbackTokenAsync to get an Exchange token for reaching the mailbox through EWS from its backend, or getUserIdentityTokenAsync to identify the user to its own services. Microsoft has turned legacy Exchange Online user identity tokens and callback tokens off across all Microsoft 365 tenants; Exchange user identity tokens remain supported only for Exchange on-premises. An add-in still built on this pattern needs its authentication replaced, not adapted.

Pattern 2: Legacy Office single sign-on with getAccessToken. The add-in calls getAccessToken to get an access token for its own web API; to reach Microsoft Graph, the server-side code exchanges that token through the OAuth 2.0 on-behalf-of flow and calls Graph itself. This still works, but Microsoft now describes it as a legacy pattern, to be used only when maintaining an existing add-in or supporting older Outlook clients on platforms without NAA.

Pattern 3: MSAL with nested app authentication (NAA). The add-in uses MSAL.js, brokered by the Office host, to get Microsoft Graph tokens with single sign-on, and can call Graph from client code without a middle-tier server. This is the route Microsoft recommends for Outlook add-ins that need delegated user access or user identity. It needs a specific single-page-application redirect URI (brk-multihub:// plus your add-in’s domain) in the app registration, and a fallback for older Office hosts that do not support NAA, such as signing in through the Office dialog API.

The migration mistake to avoid: changing authentication patterns and EWS-to-Graph operation migration in the same workstream. Authentication changes deserve their own focused work, with their own testing. Bundling them together produces failure modes that are harder to diagnose. If you are on Pattern 1, the authentication change is unavoidable, so schedule it as its own workstream rather than folding it into the operation migration.

What to Do If Your Migration Will Not Finish in Time

If it becomes clear the migration will not complete before customers’ tenants start blocking EWS, the structured response:

Confirm the gap honestly. Identify exactly which functionality is still EWS-dependent, the user impact if it stops working in a given tenant, and the revised completion timeline, which has to end before 1 April 2027.

Work with customers’ administrators on the allow list. There is no request to file with Microsoft: each tenant’s administrator decides which App IDs go on EWSAllowedAppIDs. Give your customers the App IDs your add-in uses for EWS, explain why and for how long they are needed, and attach your documented migration completion date. A tenant that Microsoft has already switched to False can re-enable EWS with an allow list until final deprecation, but only after a service interruption.

Communicate with affected customers. If your add-in serves customers, they need to know there is an interruption risk and the timeline for resolution. Microsoft’s seven-day warning goes to each tenant through Message Center, so do not assume you will see it before your customers do. In our view, customers tolerate a clearly communicated delay far better than a surprise.

Continue the migration work at maximum sustainable pace. The allow list is a bridge, not a destination, and it ends on 1 April 2027. Keep the engineering focus on completion.

Run the post-mortem properly afterward. When the migration completes, capture the lessons. The next Microsoft platform migration will have similar shape; the value of the lessons compounds.

What McKenna Delivers

McKenna Consultants offers two engagement models for EWS to Microsoft Graph migration:

Compressed-timeline migration delivery. A packaged engagement designed for the situation this article describes — Outlook add-in with substantial EWS dependency, customers’ tenants moving to restricted EWS access, limited team capacity. We deliver the migration as a focused project with the structured sprint plan above, scoped to the size of your add-in’s EWS footprint, up to sixteen weeks.

Migration audit and acceleration support. A shorter engagement for teams who are running the migration themselves but want experienced backup. We perform the architectural review, identify the highest-risk areas, and provide structured input on the sprint plan, scoped at three to six weeks of advisory plus targeted implementation support.

McKenna Consultants has been building custom Microsoft Office add-ins for over two decades. For Workiro, we built an Outlook add-in with a Microsoft Graph server-side integration that lets users tag, import and sync email conversations into the Workiro platform. We are a UK-based custom Outlook add-in development consultancy with practitioner depth on Microsoft Graph, MSAL, and the modern Office Add-ins platform.

If your organisation is running the EWS migration sprint against Microsoft’s phased retirement, contact us. Microsoft has said there will be no exceptions past April 2027; the engagement starts the conversation that gets you across it.

Sources

• Microsoft Learn — Deprecation of Exchange Web Services in Exchange Online: the 2018 and 2023 announcements, the parity-gap roadmap (including user configuration objects), and EWS starting to be disabled in October 2026 and fully disabled in April 2027.
• Microsoft Exchange Team Blog — Exchange Online EWS, Your Time is Almost Up: tenant-by-tenant disablement through EWSEnabled, re-enabling until final deprecation (with a service interruption after a block), “near-complete feature parity”, full and permanent disablement from 1 April 2027 with no exceptions, and no change to EWS in Exchange Server.
• Microsoft Exchange Team Blog — EWS Deprecation Is Here – What This Means To You: the deprecation starting on 1 October 2026, the allow list required from 10 October where EWSEnabled is True, the second phase switching Null tenants to False with a seven-day Message Center warning, allow lists populated from 60 days of usage, and 24 hours for allow-list changes to take effect.
• Microsoft Exchange Team Blog — Introducing EWSAllowedAppIDs: Preparing for the Final Phase of EWS Retirement: what the tenant-level AppID allow list is and how it works with EWSEnabled.
• Microsoft Learn — Exchange Web Services (EWS) to Microsoft Graph API mappings: Graph equivalents for EWS operations, including SendItem, ResolveNames, ConvertId, availability, and push and pull notifications.
• Microsoft Learn — subscription resource type: subscription lifetimes for Outlook resources and clientState validation.
• Microsoft Learn — Reduce missing subscriptions and change notifications: lifecycle notifications and the lifecycleNotificationUrl requirement.
• Microsoft Learn — Authentication options in Outlook add-ins: legacy Exchange Online identity and callback tokens turned off in all Microsoft 365 tenants, MSAL with NAA recommended, and getAccessToken SSO as a legacy pattern.
• Microsoft Learn — Use legacy Office single sign-on (SSO) in an Office Add-in: the server-side on-behalf-of exchange needed to reach Microsoft Graph.
• Microsoft Learn — Enable single sign-on in an Office Add-in with nested app authentication: the NAA redirect URI, supported hosts, and fallback for hosts without NAA.
• Microsoft Learn — Use Exchange Web Services (EWS) from an Outlook add-in in Exchange on-premises: makeEwsRequestAsync guidance scoped to Exchange on-premises.