Microsoft EWS End-of-Life: Why SaaS Teams Need to Rebuild Customer-Facing Outlook Integrations Before October 2026

The Microsoft EWS end-of-life deadline is the single most under-priced piece of engineering work on most SaaS roadmaps right now. On October 1, 2026, Microsoft will stop responding to Exchange Web Services (EWS) API calls for Exchange Online, and every product that reads or writes email, calendar, or contacts against a customer's Outlook or Microsoft 365 tenant via EWS will break. If your product is one of them, you have months, not quarters, to migrate. And if you are a multi-tenant SaaS company whose customers rely on this integration to do their day jobs, you cannot afford a migration that leaks data, drops sync, or locks users out of email during cutover.

We are seeing this land hard in conversations with engineering leaders across usage-based SaaS, revenue operations tools, sales engagement platforms, customer success software, and go-to-market tooling more broadly. Products that were built on EWS three to five years ago, when EWS was the cleanest API for Exchange, are now sitting on a deprecation cliff with a hard date. This post covers why the Microsoft EWS end-of-life is different from a routine API migration, what breaks if you wait, what the migration to Microsoft Graph actually looks like in production, and how to think about the integration layer so that you are not in the same position the next time Microsoft ships an API change.

What the Microsoft EWS End-of-Life Actually Means

EWS is a SOAP-based API that Microsoft launched in 2007 as part of Exchange 2007. For more than a decade it was the canonical way to programmatically interact with Exchange mailboxes. Customer-facing SaaS products used EWS for the things that matter most in B2B: read a user's inbox, sync calendar events, post new meetings, update a contact, fetch folder state. Thousands of products still use it.

In late 2022, Microsoft announced that EWS would be retired for Exchange Online. The original deadline slipped, as these deadlines tend to, but the current cutoff is October 1, 2026, per Microsoft's official deprecation guidance. After that date, EWS requests against Exchange Online tenants will fail. The replacement is Microsoft Graph, which is a REST and JSON API over OAuth 2.0 with a fundamentally different permission model, a different throttling regime, and different primitives for change notifications.

For product teams, the Microsoft EWS end-of-life is not a "swap one HTTP client for another" migration. It is a rewrite of the auth layer, the permissions model, the sync engine, the change notification pipeline, and in many cases the data model itself. The surface area involved is large, and every one of those pieces is visible to end users when it breaks.

Why This Is Harder Than It Looks

The first thing engineering teams underestimate is the permissions migration. EWS supported basic authentication for years and later added OAuth, but the scope model was coarse. Products could ask for FullAccess to a mailbox and get it. Microsoft Graph requires granular delegated or application permissions, and admins must consent to each scope explicitly. For a multi-tenant product, that means the tenant admin has to approve the new Graph permissions for every customer, and the re-consent has to happen before the EWS deadline. Any customer that does not complete re-consent loses the integration on October 1.

The second issue is the throttling and rate-limit regime. EWS throttling was per-mailbox and reasonably forgiving. Microsoft Graph is multi-dimensional, with tenant-level, application-level, and per-mailbox limits that interact. Products that were cavalier about request pacing under EWS will find themselves throttled or even blocked on Graph, especially in bulk-sync or backfill scenarios. This is the kind of behavior you need to discover in load testing, not in the first enterprise customer's weekly reporting window.

The third issue is the change-notification model. EWS had streaming and pull subscriptions. Microsoft Graph uses webhook-style subscriptions with a registered endpoint, lifecycle events, validation handshakes, and a maximum lifetime that requires periodic renewal. That renewal loop has to be built, monitored, and alerted on, per tenant. If a subscription quietly expires and your product does not renew, you stop receiving email events until someone notices. Most teams notice when a customer calls support.

The fourth issue is object fidelity. EWS exposed a rich Exchange-native model. Graph exposes a REST-friendly abstraction that covers most but not all of the same surface. Products that rely on specific EWS capabilities, like custom extended properties or certain folder operations, have to redesign the feature or accept a reduced experience on Graph. For customer-facing Outlook integrations in CRM, revenue intelligence, and scheduling tools, this usually means reworking the data contract between the integration layer and the product.

The fifth issue is multi-tenancy at scale. A B2B SaaS product with thousands of connected Microsoft 365 tenants is not migrating one integration; it is migrating thousands of integrations, each with its own admin consent state, its own token refresh state, and its own sync state. Orchestrating that migration without downtime is a project in itself, and it is not a project that maps neatly onto a two-week sprint.

Why In-House Rewrites Keep Blowing Up

We have written before about why building integrations in-house breaks down at scale, and the Microsoft EWS end-of-life is a textbook illustration of the thesis. Engineering teams that own their Exchange integration from auth to sync to UI spent the original implementation budget on reading and writing email. They did not budget for the next Microsoft API generation. When that generation arrives on a fixed deadline, the entire team has to drop what they were doing and rebuild the foundation.

The pattern we see is predictable. A product manager scopes "migrate to Graph" as a two-quarter effort. The engineering lead pushes back because the permissions, throttling, change-notification, object-fidelity, and multi-tenant cutover workstreams are each two to three quarters on their own. Someone on the leadership team asks whether a third-party platform could absorb the work. The CTO does the build-versus-buy math and realizes that owning the integration layer was never the thing that made the product valuable. It was the thing that ate the team's calendar while the real roadmap languished.

The second pattern: teams that rushed the Graph migration in 2024 or 2025 to get ahead of the deadline are now maintaining two parallel sync pipelines, one on EWS for legacy tenants that have not re-consented and one on Graph for the migrated cohort. Every code change has to be made twice. Every bug report has to be debugged twice. The cost of the dual stack accumulates until the team forces the EWS sunset for their own sanity, which then pushes the customer-side problem onto support and CS.

Industry Context: Microsoft Is Not the Only One Moving

Zoom in and the Microsoft EWS end-of-life is a specific deadline. Zoom out and it is part of a broader shift across every major system of record. Salesforce is continuing to evolve its API surface, deprecating older endpoints and requiring newer OAuth flows - even offering Salesforce Headless 360. HubSpot has tightened rate-limiting and changed webhook semantics more than once in the last three years. Microsoft Dynamics 365 has its own cadence of API changes. Gong, Zendesk, Marketo, and the long tail of SaaS apps each run their own deprecation schedule. The underlying trend is that the owners of systems of record are tightening control over how third-party products access their data, usually for good reasons around security and performance, and those tightening cycles land on SaaS integration teams as forced rewrites.

Gartner and other analysts have been writing about this for years under various labels, including "integration debt" and "composable enterprise." The version we care about here is specific: if your product is customer-facing and depends on an external system of record, you will be forced to rewrite that integration roughly every 18 to 36 months. Not because you want to, but because the upstream vendor changed the contract. The question is whether that rewrite consumes your product team or happens in the infrastructure layer beneath them.

The companies we have advised that handle these cycles gracefully share one trait: they have moved their integration layer out of application code and into infrastructure. The auth layer, the sync engine, the change-notification reconciliation, and the per-tenant observability all live in a dedicated integration platform. When Microsoft ships Graph subscriptions v2 in 2028 or Salesforce deprecates another endpoint in 2027, the platform absorbs the change and the product team keeps shipping features. When those primitives live inside the product, every deprecation cycle is a quarter-long fire drill.

What a Clean Graph Migration Looks Like

The shape of a Microsoft EWS end-of-life migration that does not blow up the roadmap has a few non-negotiable pieces. First, auth is modernized to OAuth 2.0 with Graph-scoped permissions, and the re-consent flow is automated across every connected tenant. Users get a clear in-product prompt, admins get a clear scope list, and the product tracks consent state per tenant so it knows exactly which customers have been migrated and which have not.

Second, the sync engine is rebuilt around Graph subscriptions with a lifecycle manager that renews subscriptions before expiry, handles missed events through delta queries, and gracefully degrades to polling if subscriptions are unavailable. Every one of those behaviors is declarative and observable per tenant.

Third, throttling awareness is baked in. The integration platform respects Graph's throttling headers, backs off intelligently, and distributes load across time windows so that bulk backfills do not collide with real-time sync. This is the kind of behavior that separates a production-grade integration from a demo.

Fourth, bulk grants and delegated access patterns are first-class. For customer-facing Outlook integrations, the difference between "each end user has to authorize the app individually" and "the tenant admin grants once and users are covered" is the difference between 15% adoption and 90% adoption. If your product supports bulk grants, your customers deploy it successfully. If it does not, your integration is theoretically available and practically unused.

Fifth, the cutover from EWS to Graph is tenant-by-tenant, not flag-day. The integration platform supports running both stacks side by side during the transition, routing each tenant to the appropriate implementation based on its migration state, and retiring EWS only once every tenant is on Graph. This is how you avoid an outage for slow-moving customers while still retiring the legacy stack cleanly.

How Ampersand Handles the Microsoft EWS End-of-Life

Ampersand is the integration infrastructure layer for product developers. It is built for exactly the pattern described above: native, customer-facing, enterprise-grade integrations with systems of record, owned by the product team but not maintained by them.

For Microsoft 365, that means managed authentication with automatic token refresh and scope-aware re-consent, Graph-backed reads and writes for mail, calendar, and contacts, Graph subscriptions with lifecycle management, delta-query-based reconciliation for missed events, support for bulk admin grants, and tenant-level dashboards with error logs and quota visibility. The declarative, YAML-based framework means the Outlook integration is checked into your repo alongside the rest of your integration code, version-controlled, and CI-friendly.

For teams consolidating multiple integrations in the same migration window, the platform covers the rest of the stack at the same time. Salesforce, HubSpot, Gmail, Marketo, Microsoft Dynamics 365, Zendesk, Gong, and hundreds of long-tail systems are available through the same declarative framework. A team that is rebuilding its Outlook integration for the Microsoft EWS end-of-life can, in the same project, modernize its Gmail integration, retire its legacy polling-based Gong ingestion, and stand up a Zoom connector, all through Ampersand's how-it-works architecture. The economics flip: instead of building and maintaining one integration at a time, you define them declaratively and the platform handles the operational layer.

The customer proof points are concrete. 11x, the AI phone agent company, cut AI phone agent response time from 60 seconds to 5 seconds after moving onto Ampersand, because the CRM context flow shifted from a chain of in-house API calls to a managed integration layer. Hatch, the home services engagement platform inside Yelp, has its CTO saying "Ampersand lets our team focus on building product instead of maintaining integrations. We went from months of maintenance headaches to just not thinking about it." Both are shipping customer-facing product integrations at scale, and both use Ampersand as the chassis.

Approach Comparison for the EWS Migration

The honest read on this table is that unified APIs and embedded iPaaS can work for teams whose Outlook integration is shallow, do not need real-time or near-real-time flows, and whose tolerance for fidelity loss is high. For teams whose product integration is a core part of the value proposition, where users notice the moment a calendar sync drops or an email thread goes stale, the platform needs to be closer to the application and more expressive. That is the gap Ampersand was built for.

The Ampersand Sell

If you are currently scoping the Microsoft EWS end-of-life migration, the highest-leverage decision you will make this year is where the integration layer lives. Owning it in application code means your product team is on the hook for this migration and every Graph-v2, Salesforce-v63, and Gong-v5 migration that follows. Moving it into dedicated integration infrastructure means your product team gets those cycles back.

Ampersand gives you bi-directional read and write real-time integrations with Microsoft Graph, Gmail, Salesforce, HubSpot, Marketo, Microsoft Dynamics 365, Zendesk, Gong, NetSuite, SAP, Sage, and hundreds more connectors, all through a single declarative, YAML-based framework. You get custom objects and dynamic field mapping, managed auth with refresh and scope handling, scheduled reads, backfills, bulk-write optimization, on-demand read and write API endpoints, CI/CD support, version control, and dashboards with logs and alerting. The platform is GDPR-compliant and ISO-certified, so enterprise security reviews do not become the migration's hidden critical path.

The best next step for a product or engineering leader running this evaluation is to walk through how Ampersand works end to end, then open the Ampersand documentation and map the specific Microsoft Graph scopes your product depends on to the declarative configuration. Most teams that go through that exercise finish with a clear migration plan in a single afternoon.

FAQ

When exactly does the Microsoft EWS end-of-life hit, and is the date firm?

The current published deadline is October 1, 2026, for Exchange Online. Microsoft has slipped this date once before, but has signaled unusually firmly that the 2026 date is the final one, and they have begun throttling EWS traffic in advance of the cutover. The safe assumption for planning is that EWS requests against Exchange Online tenants will fail starting October 1, 2026. On-premises Exchange deployments are a separate conversation and follow a different lifecycle.

Can we do the EWS to Graph migration without disrupting customers?

Yes, if you plan the cutover tenant-by-tenant. The pattern that works is running both stacks in parallel during the transition, routing each tenant to the EWS implementation or the Graph implementation based on its migration state, and retiring EWS only once every tenant is on Graph. This requires a state machine per tenant and a re-consent flow that is smooth for the admin. Building that machinery in application code is possible but expensive, which is why teams that care about zero-disruption migrations typically move it into the integration layer.

What are bulk admin grants and why do they matter for Outlook integrations?

Bulk admin grants let a tenant administrator consent to the app's Graph permissions on behalf of every user in the tenant, rather than requiring each user to go through their own OAuth flow. For customer-facing Outlook integrations in CRM, revenue intelligence, and scheduling products, bulk grants are the difference between 15% adoption and 90% adoption. Any integration platform you evaluate for the Microsoft EWS end-of-life migration should support bulk grants natively, and the re-consent flow should propagate across the tenant without requiring end-user action.

How does this migration interact with Salesforce and HubSpot integrations?

Most SaaS products that have an Outlook integration also have a Salesforce or HubSpot integration, and the two are often intertwined. If your integration layer is a grab-bag of per-system HTTP clients, the Microsoft EWS end-of-life forces you to modernize the Outlook side while the Salesforce and HubSpot sides continue to age. The more efficient approach is to move all of them onto a single integration infrastructure platform in the same project, which is the approach we describe in the best tools for CRM integration in 2026.

What about sync latency and real-time email events on Graph?

Microsoft Graph supports webhook-style subscriptions that deliver events within seconds of a mailbox change. The operational challenge is renewal: subscriptions have a maximum lifetime (typically 4230 minutes for most resources) and must be renewed before expiry. Products that fail to renew lose their event stream silently. Ampersand manages subscription lifecycles automatically, which removes this class of bug from your product team's plate.

How do we avoid ending up in the same situation five years from now?

Move the integration layer out of application code and into infrastructure. The reason the Microsoft EWS end-of-life is painful is that most products coupled their business logic directly to EWS-specific primitives. If your product reads and writes through a declarative integration platform, the next deprecation cycle is absorbed at the platform layer and does not reach your application code. We have written about this pattern at length in what is integration infrastructure.

Conclusion

The Microsoft EWS end-of-life is not a routine API migration. It is the forcing function that exposes whether your product treats integrations as core infrastructure or as application code. Teams that rebuild their Outlook integration in the application layer will survive this deadline and then repeat the exercise on every future Microsoft, Salesforce, and HubSpot deprecation cycle. Teams that move the integration layer into dedicated integration infrastructure rebuild once, absorb this migration, and get those engineering cycles back permanently.

If the October 2026 deadline is on your roadmap, the time to scope the chassis is now, not in Q3. You can start with Ampersand, walk through the full architecture in how it works, and map your Graph migration against the Ampersand documentation. The product teams that come out of this migration strongest will be the ones that used it as the excuse to upgrade the foundation under the entire integration surface, not just the Outlook corner of it.