--- title: "EWS Shuts Down Oct 2026: The SaaS Guide to Microsoft Graph Migration" slug: ews-shuts-down-oct-2026-the-saas-guide-to-microsoft-graph-migration date: 2026-05-21 author: Raaj categories: [General] excerpt: "EWS for Exchange Online is disabled starting Oct 1, 2026. Here's what breaks, what Graph API still can't do, and how to migrate your SaaS integration without data loss." tldr: "Microsoft disables EWS for Exchange Online on Oct 1, 2026 (permanently by April 2027). SaaS teams must rewrite to Graph API — a 5–7 month effort involving auth overhaul, throttling redesign, and sync state migration." canonical: https://clonepartner.com/blog/ews-shuts-down-oct-2026-the-saas-guide-to-microsoft-graph-migration/ --- # EWS Shuts Down Oct 2026: The SaaS Guide to Microsoft Graph Migration **Exchange Web Services (EWS) for Exchange Online is being disabled starting October 1, 2026.** If your SaaS product reads email, syncs calendars, or manages contacts via EWS, your integration breaks on that date — or sooner. This is not a soft deprecation with a sunset blog post and a vague timeline. EWS will be disabled by default (`EWSEnabled=False`) in Exchange Online tenants that have not explicitly chosen to keep it enabled with an AllowList, and that will block EWS for all applications in the tenant at that time. By April 2027, EWS is fully disabled — no exceptions, no re-enablement. For multi-tenant SaaS companies whose products integrate with customer Outlook/Microsoft 365 inboxes, this is the most under-priced engineering work on your roadmap right now. The migration to Microsoft Graph API is not a weekend project. It is a full protocol rewrite, an auth model overhaul, and a throttling redesign — all while keeping existing customer syncs alive. For a broader view of Microsoft's 2026 deprecation wave — including SharePoint Server 2016/2019 and Office Online Server — see our [Microsoft 2026 End-of-Support Timeline](https://clonepartner.com/blog/blog/microsoft-2026-end-of-support-timeline-migration-guide/). ## What Exactly Stops Working on October 1, 2026 Microsoft will use a phased, admin-controllable disablement plan that starts in October 2026 and concludes with a complete shutdown of EWS in 2027. Here is the exact sequence your engineering team needs to internalize: | Date | What Happens | |---|---| | **End of June 2026** | EWS access blocked for all mailboxes on Exchange Online Kiosk, F1, and F3 licenses — these licenses never included EWS rights, but enforcement was never applied until now. | | **End of August 2026** | Deadline to configure an AppID AllowList and set `EWSEnabled=True` if you need more time. | | **October 1, 2026** | EWS will be disabled by default in Exchange Online tenants that have not explicitly set `EWSEnabled=True` with an AllowList. EWS calls will be blocked unless the tenant has already taken admin action. | | **April 1, 2027** | There will be no exceptions past April 2027. EWS is permanently shut off. | > [!CAUTION] > **The Kiosk/F1/F3 trap:** Many SaaS companies test their integrations against standard E3 or E5 enterprise licenses and miss this entirely. If your SaaS serves enterprise customers with retail workers, factory staff, or field technicians, your integration will silently fail for a subset of users months before the October deadline. This creates a support nightmare where the integration works for the management team but fails for the frontline staff. Microsoft modified this date to end of June 2026 based on customer feedback — but that window is closing. Starting July 1, 2026, requests to use EWS without a suitable license will result in an HTTP 403 response. **Why is Microsoft doing this now?** Two reasons. First, EWS was built nearly 20 years ago, and while it served the ecosystem well, it no longer aligns with today's security, scale, or reliability requirements. Second: the Midnight Blizzard security incident in January 2024 involved EWS and elevated the urgency of the EWS deprecation effort. The scope was also widened from third-party applications to include all Microsoft applications. In that breach, Russian state-sponsored actors used the legacy test OAuth application to grant them the Office 365 Exchange Online `full_access_as_app` role — a permission that is part of the Exchange Web Services (EWS) API. This applies only to Microsoft 365 and Exchange Online (all environments); there are no changes to EWS in Exchange Server on-premises. If some of your customers still connect on-prem Exchange mailboxes, Graph is not a universal replacement and you may need a split architecture or customer segmentation plan. ### The Temporary Bypass: AllowList + EWSEnabled If you still need to use EWS after October 2026, you have two choices: set `EWSEnabled` to `True` and maintain an AllowList, or set `EWSEnabled` back to `Null`, which re-enables EWS without restrictions until the final deprecation. But this is a bridge, not a solution. After April 1, 2027, EWS access will be permanently removed with no re-enablement. For SaaS companies, the AllowList approach has a critical dependency: **you do not control your customers' tenants.** Each customer's admin must add your application's AppID to their AllowList and set `EWSEnabled=True`. That is a support burden you do not want to carry into 2027. Microsoft may also perform temporary "scream tests" — shorter periods when they turn EWS off and back on — to help expose hidden dependencies before the final cutoff. If your product does not handle EWS failures gracefully today, those scream tests will surface as customer-reported outages. ## EWS vs. Microsoft Graph: The Architectural Differences This is not a find-and-replace migration. EWS and Microsoft Graph are architecturally different systems. | | **EWS** | **Microsoft Graph** | |---|---|---| | **Protocol** | SOAP over HTTPS (XML envelopes) | REST over HTTPS (JSON payloads) | | **Auth Model** | NTLM, Kerberos, Basic Auth (deprecated Oct 2022), OAuth 2.0 | OAuth 2.0 only (via Microsoft Entra ID) | | **Access Scope** | Broad — `full_access_as_app` grants full mailbox access | Granular — `Mail.Read`, `Calendars.ReadWrite`, individual scopes | | **Concurrency** | Up to 27 concurrent connections per mailbox | 4 concurrent requests per app ID + mailbox | | **Throttling** | Custom throttling policies configurable per-tenant | Fixed service limits — not customer-configurable | | **Notifications** | Streaming, push, and pull subscriptions | Webhooks (change notifications) and delta queries | | **SDK** | EWS Managed API (.NET), EWS Java API | Microsoft Graph SDKs (JS, .NET, Python, Java, Go) | ### Auth: From All-or-Nothing to Granular Scoping Microsoft Graph mandates OAuth 2.0 via Microsoft Entra ID. This introduces the principle of least privilege. Instead of granting an app total access to a mailbox, admins can now assign granular scopes such as `Mail.Read` or `Calendars.ReadWrite`. For multi-tenant SaaS, this means re-engineering your consent flow. Each customer tenant admin must approve your specific Graph permission scopes. If your current EWS integration uses `ApplicationImpersonation`, you are moving to application-level Graph permissions with tenant admin consent — a different workflow that needs UX investment. One trap to watch for: shared and delegated folder subscriptions require the corresponding **application** permission, not `Mail.Read.Shared`, `Calendars.Read.Shared`, or their peers, for change notifications on shared or delegated folders. ([learn.microsoft.com](https://learn.microsoft.com/en-us/graph/migrate-exchange-web-services-authentication)) Access tokens expire every 60–90 minutes, and refresh tokens last 90 days before requiring re-authentication. Your token management layer must handle this lifecycle without interrupting customer syncs. ### Throttling: The 4-Connection Ceiling This is the single biggest operational surprise for SaaS teams migrating from EWS to Graph. The documented Outlook service limits are: 10,000 API requests in a 10-minute period per app ID + mailbox, 4 concurrent requests per app ID + mailbox, and 150 MB upload (PATCH, POST, PUT) in a 5-minute period per app ID + mailbox. These per-mailbox throttling limits for Outlook in Microsoft Graph are fixed service limits and are not customer-configurable. Compare this to EWS, where there are 27 concurrent connections allowed in Exchange Online and throttling policies were configurable by tenant admins. If your product does bulk mail syncs, calendar operations, or attachment pulls, you need to completely rethink your concurrency model. > [!WARNING] > **Practical impact:** A developer reported that moving 1,000 mailbox items via Graph took 6 minutes versus 1 minute on EWS, due to the lower concurrent connection limits and different batch execution behavior. For high-volume SaaS workloads, a naive port from EWS to Graph will produce unacceptable latency. When a throttling threshold is exceeded, Microsoft Graph returns HTTP status code 429 Too Many Requests. It returns a suggested wait time in the response header of the failed request. You must implement exponential backoff with jitter, respect `Retry-After` headers, and distribute load across mailboxes. If your application ignores the `Retry-After` header and continues to poll, Microsoft will temporarily block your application entirely. Batched requests are still throttled per subrequest, and SDK auto-retry does not rescue throttled items inside a batch. ### Sync Model: Delta Queries and Webhooks In EWS, developers relied on Streaming Notifications or Push/Pull Subscriptions and `SyncFolderItems` with a mailbox-wide `SyncState` string to track changes. Graph replaces this with two mechanisms: **Change Notifications** (Webhooks) and **Delta Queries**. Graph's delta tracking is not mailbox-wide the way many EWS apps assume. Messages are delta-tracked per **mail folder**. Contacts are delta-tracked per **contact folder**. Tasks are delta-tracked per **task list**. Calendar delta on v1.0 is tied to a **calendarView** date range. If your current connector stores one watermark per mailbox, expect a data model change. ([learn.microsoft.com](https://learn.microsoft.com/en-us/graph/delta-query-messages)) Graph Webhooks require a public-facing HTTPS endpoint that can respond to validation requests within seconds. Outlook message, event, and contact subscriptions have a max lifetime of **under seven days**, and rich notifications drop to **under one day**. Microsoft caps Outlook subscriptions at **1,000 active subscriptions per mailbox across all apps**. Subscription renewal and quota management become first-class ops work, not background glue code. ([learn.microsoft.com](https://learn.microsoft.com/en-us/graph/change-notifications-overview)) > [!WARNING] > If a subscription drops, you must fall back to a Delta Query to catch missed events. When Graph sends `missed` or `subscriptionRemoved` lifecycle notifications, repair with delta instead of assuming webhooks are lossless. Also note Microsoft's warning not to send `/reauthorize` and `PATCH /subscriptions/{id}` within the same 10-minute window — use a single PATCH to renew and reauthorize together. This dual-sync architecture is something EWS never required. ### ID Behavior: The Immutable ID Trap In EWS, an `ItemId` changes if a user moves an email to a different folder. EWS developers built complex tracking logic to handle this. Microsoft Graph introduces **Immutable IDs**, but you must explicitly opt in by appending the HTTP header `Prefer: IdType="ImmutableId"` to all Graph requests. By default, Graph IDs also change when items are moved. If you fail to request Immutable IDs, your SaaS will create duplicate records every time a user organizes their inbox. Even with Immutable IDs enabled, the ID only stays stable within the same mailbox — moving an item to an archive mailbox or exporting and re-importing it changes the immutable ID. ([learn.microsoft.com](https://learn.microsoft.com/en-gb/graph/outlook-immutable-id)) ## The Missing Endpoints: What Graph API Still Can't Do There are a few major EWS feature areas that the Microsoft Graph API doesn't fully support. As of mid-2026, the confirmed parity gaps include: - Archive mailbox access, public folder CRUD, mailbox import/export (for Groups and public folder mailboxes), and recurring event delta queries. - Microsoft has decided to restrict programmatic access to public folders to supported Outlook clients only, and for bulk import/export purposes. They will not provide APIs for programmatically creating, reading, updating, and deleting public folders after October 2026. - Event delta for recurring events and Sticky Notes CRUD remain outstanding. Microsoft has shipped two bridge mechanisms: 1. **Graph Mailbox Import/Export APIs** — reached general availability in May 2026, providing a production-ready replacement for EWS-based mailbox migration. 2. **Exchange Admin API** — fills in the current gaps in Graph coverage to allow developers of EWS applications to migrate their code to a newer platform in a way that maintains functionality. But developers should continue to focus on writing code that leverages Graph APIs with as little use of the Exchange Admin API as possible, because apps that move from EWS to the Exchange Admin API face going through two separate code migrations. > [!NOTE] > **Public Folders:** If your SaaS product relies on EWS public folder operations, there is no Graph replacement coming. Microsoft has explicitly stated this functionality will not be available via APIs. Advise customers to migrate to Shared Mailboxes or Microsoft 365 Groups before your EWS integration shuts down. ## The 5 Data Types You Must Migrate Cleanly Every EWS-to-Graph migration touches five core data types. Each has unique pitfalls. ### 1. Messages (Mail) Mail operations (`FindItems`, `GetItem`, `CreateItem`, `SendItem`) map fairly cleanly to Graph's `/messages` and `/sendMail` endpoints. The traps: - **Delta is per folder, not per mailbox.** Inbox, Sent Items, and custom folders each need separate state. Microsoft limits filtered message delta queries to `receivedDateTime` expressions and says filtered delta returns only up to 5,000 messages — making giant catch-up queries a bad backfill plan. ([learn.microsoft.com](https://learn.microsoft.com/en-us/graph/delta-query-messages)) - **Search limitations:** Microsoft Graph `$search` works only for a limited set of message properties (approximately 15). Graph cannot apply `$filter` to properties that are collections of complex objects (such as `toRecipients`, `ccRecipients`, or `bccRecipients`). Use `$search` for filtering based on recipients. Graph does not support combining `$filter` and `$search` in a single query. - **Notifications migration:** If your product uses EWS streaming or push notifications to detect new mail, the migration to Graph change notifications (webhooks) requires rebuilding your notification processing infrastructure to receive and validate HTTPS POST messages. If you are currently using EWS pull notifications, Microsoft recommends using `Get messages delta`. If you have stored EWS item IDs, use Graph's `translateExchangeIds` for crosswalk purposes, but do not confuse ID translation with state migration. The safer pattern is to start shadow sync with `ImmutableId`, keep an EWS-to-Graph crosswalk temporarily, and compare folder counts plus representative item samples before you switch writes. ### 2. Calendar Events Calendar operations are the highest-risk data type in an EWS-to-Graph migration. The danger is **de-duplication.** During cutover, if your sync engine reads from both EWS and Graph simultaneously — or if historical sync state is not properly preserved — customers get duplicate calendar entries. Key issues: - **Recurring events:** Graph API lacks full recurring event delta support as of this writing. If your product syncs recurring event exceptions, test this exhaustively. To query recurring meetings, you must use the `/calendarView` endpoint to expand recurrences rather than the standard `/events` endpoint — otherwise you will miss exceptions like a user moving one instance of a weekly meeting. - **Event IDs:** EWS `ItemId` values do not map to Graph event IDs. Your sync state table that tracks which events have been synced is invalid. Use `iCalUId` as your primary reconciliation key — it is stable across both APIs. - **Attendee status:** Graph uses a different schema for attendee responses. If your product writes back acceptance/decline states, rebuild that mapper. - **Timezone corruption:** When expanding recurring events, be explicit about timezone handling. Silent timezone mismatches are a common source of off-by-one-hour meeting times after migration. Test recurring series edits, moved occurrences, cancelled instances, organizer changes, and time-zone shifts inside the exact date windows your product syncs. If you do not, you can have both systems "succeed" technically while users see double-booked or resurrected meetings. ### 3. Contacts Contacts move from EWS `Contact` items to Graph's `/contacts` endpoint. The data model is similar but not identical. Delta tracking is per **contact folder**, not per mailbox. If your current EWS code assumes one flat address book, you need to inventory folders first and carry separate folder state through the migration. Extended MAPI properties that some SaaS products rely on require Graph's `singleValueExtendedProperties` or `multiValueExtendedProperties` resources — or you can migrate them to Graph Open Extensions or Schema Extensions. This requires mapping legacy MAPI property tags to JSON extension payloads. Validate your field mapping against production data, not test accounts with three contacts. ### 4. Tasks EWS tasks — stored in the Exchange Tasks folder — map to Microsoft Graph's To Do API. Note that this is a more significant shift than the mail and calendar migrations: the underlying data model differs. The To Do API has different status values, different recurrence patterns, and a richer linked resources model. You cannot map EWS Tasks directly; you must rewrite your integration to use the `/me/todo/lists` and `/me/todo/lists/{id}/tasks` endpoints. The permission story varies by operation. Listing tasks supports application permission `Tasks.Read.All`. Creating tasks does **not** support application permissions on the create endpoint. If your product creates or mutates tasks across customer tenants, validate each verb — not just the resource family — before you commit to scope design. ### 5. Attachments Attachments in EWS are fetched inline with the parent item or via `GetAttachment`. In Graph, attachments are a sub-resource of messages and events (`/messages/{id}/attachments`). The key constraints: - For files **under 3 MB**, attach them directly in the JSON payload. - For files **from 3 MB to 150 MB**, initiate an upload session using the `createUploadSession` endpoint, chunk the file into byte ranges, and upload sequentially. Upload session URLs are pre-authenticated — do not send an `Authorization` header on the `PUT`. ([learn.microsoft.com](https://learn.microsoft.com/en-us/graph/outlook-large-attachments)) - For **To Do task attachments**, the limit is 25 MB and the upload flow is different (it does require `Authorization`). - Group calendar events do not support attachments. EWS had no such thresholds. If your product handles large file attachments — common in business email — your upload path needs an overhaul. Migrate attachment code by workload, not behind one generic helper, because the failure handling differs. The new Graph Import API supports reconstructing folders, messages, calendar items, contacts, and tasks within a target mailbox, and deduplication logic ensures no duplicates if the same data is imported multiple times. If you are doing bulk operations, evaluate whether the Import/Export APIs fit your use case. ## How to Avoid Sync Gaps and Data Loss During Cutover The hardest part of this migration is not writing the new Graph code. It is cutting over without losing data or generating duplicates for your existing customers. ### Run Parallel Syncs Before Cutover Before switching off EWS, run your Graph implementation in **shadow mode** — reading the same mailboxes via Graph and comparing the results to EWS output. Do not write via Graph yet. This surfaces: - Throttling issues at your actual scale - Missing data (items EWS returns that Graph does not, due to parity gaps) - Permission gaps (scopes you forgot to request) ### Translate IDs Before You Switch Your database is filled with EWS Item IDs. You cannot use these IDs in Graph. Before cutover, use the Graph `translateExchangeIds` endpoint to convert stored EWS IDs into Graph Immutable IDs: ```json POST https://graph.microsoft.com/v1.0/me/translateExchangeIds { "inputIds" : [ "AAMkADh..." ], "sourceIdType": "ewsId", "targetIdType": "restImmutableEntryId" } ``` You are limited to **1,000 IDs per request**. If your SaaS has millions of stored EWS IDs, you cannot translate them synchronously during cutover. Build a background migration job that batches these requests, handles rate limits, and updates your database mapping tables weeks in advance. Any new items synced via EWS during this transition period must also be translated on the fly. For calendar events specifically, use `iCalUId` as your primary reconciliation key — it is stable across both APIs and eliminates the risk of duplicate creation. ### Map Sync States to Delta Tokens EWS used `SyncFolderItems` with a base64 `SyncState` string. Graph uses Delta Queries (`/delta`) with an `odata.deltaLink` URL. There is no direct translation between the two. To cut over cleanly: 1. Pause the EWS sync. 2. Execute an initial Graph Delta Query to obtain the latest `odata.deltaLink`. 3. Discard the data from the initial Delta Query (since you already have it from EWS). 4. Save the `odata.deltaLink` in your database. 5. Resume syncing using the new Delta Token. 6. Verify that no items are missed by comparing counts and checksums. ```http GET https://graph.microsoft.com/v1.0/me/mailFolders/{folderId}/messages/delta Prefer: IdType="ImmutableId" ``` That single header-plus-delta pattern is the foundation of a safer cutover: stable IDs for local state, delta links for replay, and fewer false duplicates after folder moves. > [!TIP] > Opt into immutable IDs **before** your parallel run. If you already created subscriptions without that header, you must delete and recreate them to switch notification IDs. Do not wait until go-live week to fix your ID format — subscription format, and dedupe logic have to change before you trust Graph in production. ([learn.microsoft.com](https://learn.microsoft.com/en-gb/graph/outlook-immutable-id)) ### Manage the OAuth Token Migration If your app already uses OAuth for EWS, you cannot reuse the same token for Graph. Graph tokens are resource-audience specific, so existing EWS token flows do not become Graph flows by configuration. The token must include Graph-specific scopes. This means: - You must trigger a **re-consent flow** for every connected customer - Plan this as a product-managed migration, not a silent backend swap - Communicate the change to customer admins well before cutover - Consider a gradual rollout: migrate one customer cohort at a time To minimize friction, prompt users to re-authenticate inside your SaaS dashboard prior to the October 2026 deadline. ### Handle the Concurrency Cliff Your EWS code may have been tuned for 27 concurrent connections. Graph limits you to 4 concurrent requests per app ID + mailbox. JSON batching is constrained so that Microsoft Graph sends up to 4 individual Outlook requests from a batch at a time. If you flip from EWS to Graph without rearchitecting your concurrency, you will hit 429 errors immediately. Design your sync queue to: - Process mailboxes in parallel (limits are per-mailbox) - Limit concurrency to 3 per mailbox (leave headroom below the 4-connection ceiling) - Implement token bucket rate limiting per mailbox - Use delta queries and webhooks instead of polling ### De-Duplication Strategy for Calendar Events Calendar duplicates are the #1 complaint in poorly executed EWS-to-Graph migrations. To prevent them: - Use `iCalUId` as your primary reconciliation key - Never create a new event in Graph if your mapping table already shows it was synced via EWS - After cutover, run a de-duplication pass that checks for events with identical `iCalUId` and removes any that were double-created during the transition window ## A Realistic Engineering Timeline Here is what the migration actually looks like for a SaaS product with an existing EWS integration: | Phase | Duration | Work | |---|---|---| | **Audit & scope** | 2–3 weeks | Inventory every EWS call. Use Microsoft's EWS Code Analyzer. Map each to a Graph equivalent or flag parity gaps. | | **Auth overhaul** | 3–4 weeks | Register Graph app in Entra ID. Implement consent flows. Build token lifecycle management. | | **Core API rewrite** | 6–8 weeks | Rewrite message sync, calendar sync, contact sync, task sync, attachment handling. Rebuild notification infrastructure. | | **Throttling & resilience** | 2–3 weeks | Implement retry logic, rate limiting, circuit breakers for 429/503. Load test at production scale. | | **Parallel validation** | 3–4 weeks | Shadow mode: run Graph alongside EWS, compare outputs, fix discrepancies. | | **Customer rollout** | 3–4 weeks | Re-consent flow, staged migration, monitoring, customer communication. | | **Buffer** | 2+ weeks | Edge cases, parity gap workarounds, customer-specific issues. | **Total: 5–7 months** of focused engineering effort. That assumes your team has Graph API experience. If they do not, add ramp-up time. It is important to get started with this effort as soon as possible, as the Graph API patterns are quite different from EWS. Equivalent Graph API operations may exhibit subtle differences that affect your use cases and application designs in unanticipated ways. This timeline assumes a single integration. If your product has multiple EWS touchpoints — email sync, calendar booking, contact management, task sync — each is its own migration workstream. ## Why In-House EWS Migrations Derail SaaS Roadmaps Here is the math most CTOs underestimate: this migration requires **senior backend engineers** — the same people building your product's core features. For a typical SaaS product with email/calendar integration, you are looking at 2–3 senior engineers occupied for 4–6 months. That is not just engineering cost. That is product velocity you are losing. Features that do not ship. Revenue milestones that slip. For a deeper analysis of this dynamic, see [How In-House Data Migrations Silently Kill Product Velocity](https://clonepartner.com/blog/blog/how-in-house-data-migrations-silently-kill-product-velocity/). The tricky part is that this migration generates zero customer-visible value. Your customers do not care whether you use EWS or Graph — they care that their email sync works. You are spending senior engineering capacity to maintain the status quo. Microsoft has confirmed there will be no exceptions past April 1, 2027, regardless of an organization's readiness status. You cannot request an extension beyond the final deadline. ## When to Bring in a Migration Partner Not every SaaS team should build this in-house. Consider partnering when: - **Your team lacks Graph API expertise.** OAuth consent flows, Entra ID app registrations, delta query patterns, webhook validation — it is a different world from EWS. - **You cannot sacrifice 6 months of product roadmap.** If Graph migration is not your core business, it should not consume your core engineers. - **You have complex sync state.** If your product maintains bidirectional sync with thousands of customer mailboxes, the cutover risk justifies expert help. - **You are running into parity gaps.** Archive mailboxes, public folders, recurring event deltas — these edge cases require someone who has hit them before. At ClonePartner, we have executed [1,500+ data migrations](https://clonepartner.com/blog/blog/how-we-run-migrations-at-clonepartner/) across APIs, formats, and platforms. For EWS-to-Graph migrations, we handle the SOAP-to-REST rewrite, OAuth token migration, sync state preservation, and the concurrency redesign required to work within Graph's throttling limits — all while keeping your existing customer syncs alive with [zero downtime](https://clonepartner.com/blog/blog/zero-downtime-data-migration/). The pattern we follow: 1. **Audit your EWS surface** — catalog every call, endpoint, and data type 2. **Build the Graph integration** — including retry logic tuned for 429/503 patterns 3. **Parallel validation** — shadow mode against your production data 4. **Staged cutover** — customer-by-customer, with rollback capability 5. **De-duplication sweep** — catch any sync artifacts from the transition Your engineers stay on the product roadmap. We handle the plumbing. > The October 2026 deadline does not move. If your SaaS product integrates with Exchange Online via EWS, the migration clock is already running. Talk to our team about a scoped assessment — we will map your EWS surface, flag parity gaps, and give you a realistic timeline and cost before you commit a single engineer. > > [Talk to us](https://cal.com/clonepartner/meet?duration=30) ## Frequently asked questions ### When does EWS stop working for Exchange Online? EWS begins being disabled by default on October 1, 2026. Frontline worker licenses (F1, F3) lose access at the end of June 2026. Tenant admins can temporarily re-enable EWS via an AppID AllowList, but all EWS access is permanently removed on April 1, 2027 with no exceptions. ### Does the EWS deprecation affect on-premises Exchange Server? No. The EWS retirement applies only to Exchange Online (Microsoft 365). Exchange Server 2016 and 2019 running on-premises retain full EWS support with no end-of-life date announced. ### Does Microsoft Graph have full feature parity with EWS? Not yet. As of mid-2026, Graph API still lacks full support for archive mailbox access, public folder CRUD, recurring event delta queries, and some mailbox import/export scenarios. Microsoft has explicitly stated public folder APIs will not be provided after October 2026. ### How long does an EWS to Graph API migration take? For a typical SaaS product with email, calendar, and contacts integration, expect 5–7 months of focused engineering work covering audit, auth overhaul, API rewrite, throttling redesign, parallel validation, and staged customer rollout. ### What are the Microsoft Graph API throttling limits for Outlook? Graph enforces 10,000 API requests per 10-minute period per app ID + mailbox, 4 concurrent requests per app ID + mailbox, and 150 MB upload in a 5-minute period. These are fixed service limits that cannot be increased or configured by tenant admins.