The Final Sprint: Completing Your EWS to Microsoft Graph Migration Before October 2026
Four months remain before the EWS deprecation enforcement date of 1 October 2026. For Outlook add-in development teams whose migration to Microsoft Graph is incomplete, that is not “the deadline is in October” — it is “the deadline window starts now and closes at the end of September.” A migration begun in September will not complete in September. A migration begun today might.
This article is a deliberately tactical guide for teams running the EWS to Microsoft Graph migration with the deadline visible. 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 the next sixteen weeks to make the deadline. 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.
What Happens on 1 October 2026
The EWS deprecation has been signalled for years and progressed in stages through 2025 and the first half of 2026. The critical milestones:
- September 2024: Microsoft announced the deprecation timeline.
- March 2026: EWS calls against frontline and kiosk licences began returning enforcement responses (this milestone is now behind us).
- 1 October 2026: EWS calls from third-party Outlook add-ins begin returning blocking enforcement responses across all licence categories. Add-ins relying on EWS will fail to load EWS-dependent functionality after this date.
The 1 October enforcement is not a soft cutoff. It is the date at which Microsoft begins blocking EWS calls from add-ins that have not been added to the AppID AllowList. The AppID AllowList is a temporary mechanism — a specific, bounded extension for organisations that genuinely cannot complete migration in time — but it is not a substitute for migration. We address the AllowList specifically later in this article.
Add-ins that complete migration to Microsoft Graph by 30 September continue working. Add-ins that do not, and that are not on the AllowList, do not.
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:
| EWS Operation | Microsoft Graph Equivalent | Notes |
|---|---|---|
| GetItem (mail) | GET /me/messages/{id} | Direct equivalent for most cases |
| GetItem (calendar) | GET /me/events/{id} | Direct equivalent |
| GetItem (contact) | GET /me/contacts/{id} | Direct equivalent |
| FindItem (mail) | GET /me/messages?$filter=... | Filter syntax differs from EWS query |
| FindItem (calendar) | GET /me/events?$filter=... and /me/calendarView | Use calendarView for time-window queries |
| CreateItem | POST /me/messages, POST /me/events, etc. | Direct equivalents |
| UpdateItem | PATCH /me/messages/{id}, PATCH /me/events/{id} | Direct equivalents |
| DeleteItem | DELETE /me/messages/{id} | Direct equivalent |
| SendItem | POST /me/sendMail | Different shape; review carefully |
| Notifications (push subscription) | Microsoft Graph subscriptions | Different lifecycle and renewal model |
| GetUserAvailability | POST /me/calendar/getSchedule | Direct equivalent |
| GetUserConfiguration | No direct equivalent | Often replaced by add-in’s own configuration |
| ResolveNames | GET /me/people and GET /users | Different ranking model |
| ConvertId | POST /me/translateExchangeIds | Direct equivalent for ID conversion |
The Graph surface has near-complete parity for the EWS operations that Outlook add-ins typically use. 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 surface is not the obstacle. The obstacle is doing the migration on schedule.
The AppID AllowList: When It Is Legitimate, When It Is Dangerous
Microsoft offers the AppID AllowList as a mechanism for organisations that genuinely cannot complete migration before 1 October. An add-in on the AllowList continues to be permitted to make EWS calls beyond the deadline, on a defined extension period.
The AllowList 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 use the AllowList 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 AllowList 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.
The AllowList is dangerous when it is treated as a substitute for migration:
- Adding an add-in to the AllowList is a temporary measure with a defined end date. The end date will arrive.
- The AllowList does not slow Microsoft’s EWS deprecation; it only delays the enforcement against specific add-ins.
- An organisation that uses the AllowList as a planning tool — “we’ll AllowList our add-ins and migrate later” — is buying a small amount of time at the cost of compounded risk later.
The honest position: if your add-in’s migration is realistically completable by 30 September, do not use the AllowList. Migrate. If migration genuinely cannot be completed, use the AllowList as a bridge, but do so with a hard-dated migration plan attached.
A Sixteen-Week Sprint Plan
Sixteen weeks is the realistic window from June through September. The plan that works:
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 currently uses OAuth 2.0 against Office.js, the Graph migration is largely additive. 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 that works in practice 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.
Weeks 7-9: Subscription and Notification Migration
Microsoft Graph subscriptions have a meaningfully different lifecycle from EWS push subscriptions. Subscriptions must be renewed before expiry, the renewal call requires the same authentication context that created the subscription, and missed renewals are silent. The notification payload shape is different — clientState validation, subscriptionId correlation, change type filtering — and your notification handlers must be updated.
This is often the workstream that catches teams out 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. The two patterns that work:
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 making the deadline and missing it.
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 by mid-September, with a fortnight of grace before enforcement.
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 the single most common stumble. Outlook add-ins authenticate to backend services in three common patterns:
Pattern 1: Office.js identity tokens. The add-in calls getCallbackTokenAsync to get an Exchange token, exchanges it for a Microsoft Graph token via on-behalf-of flow at the backend, and calls Graph from the backend. This pattern is broadly compatible with the migration — the same flow that produces an EWS token can produce a Graph token.
Pattern 2: Single sign-on with getAccessTokenAsync. The add-in calls getAccessTokenAsync to get a Graph-compatible token directly. This pattern is the recommended path going forward and is the simplest migration target.
Pattern 3: External authentication via MSAL popup or redirect. The add-in initiates its own authentication flow to obtain Graph tokens. This pattern works but requires additional configuration in the add-in manifest and the MSAL configuration.
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.
What to Do If You Will Miss the Deadline
If by mid-September it is clear the migration will not complete in time, the structured response:
Confirm the gap honestly. Identify exactly which functionality will be EWS-dependent on 1 October, the user impact if it stops working, and the revised completion timeline.
File an AppID AllowList request. The mechanism exists for legitimate cases. Request the AllowList for the specific add-in IDs that need it, with a documented migration completion date.
Communicate with affected customers. If your add-in serves customers, they need to know there is an interruption risk and the timeline for resolution. Customers are generally tolerant of clearly-communicated delays; they are intolerant of being surprised.
Continue the migration work at maximum sustainable pace. The AllowList is a bridge, not a destination. 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, deadline pressure, limited team capacity. We deliver the migration as a focused project with the structured sprint plan above. Typical engagement length: ten 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. Typical engagement length: three to six weeks of advisory plus targeted implementation support.
The McKenna team has delivered Outlook add-in development across two decades — including building, migrating, and supporting add-ins through the long sequence of Microsoft platform shifts that preceded EWS deprecation. 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 with the deadline visible, contact us. The October date does not move; the engagement starts the conversation that gets you across it.
