One code base for Exchange Server and Exchange Online after EWS
EWS is going away in Exchange Online and staying in Exchange Server. A product that serves customers on both, or one organization with mailboxes on both, needs EWS for one side and Microsoft Graph for the other.
Why one protocol is no longer enough
- Exchange Online: EWS is switched off tenant by tenant and for good on April 1, 2027. The replacement is Microsoft Graph.
- Exchange Server: EWS stays. Microsoft Graph does not reach mailboxes on your customers’ own servers.
A vendor cannot choose for its customers which of the two they run, and many run both during a migration that takes years.
Three ways to build it
| Approach | What you build | What it costs later |
|---|---|---|
| Two integrations behind one interface | A Graph implementation next to the EWS one, and an interface both satisfy | Every feature and every fix twice. The two behave differently in details, so each needs its own tests. |
| Graph only | A Graph implementation that replaces the EWS one | Customers on Exchange Server lose the integration, or stay on your last EWS version. |
| One EWS-shaped code path, routed by server | Nothing new in your code; the EWS library decides per call where it goes | A dependency on that library and on its coverage of the operations you use. |
What differs between the two integrations
The first approach is more work than translating calls one by one. These are the places where the Graph side needs its own design; each has a guide:
- Sign-in and mailbox access: an app registration in each customer’s tenant, consent to Graph permissions, and a mailbox scope. See impersonation in Microsoft Graph.
- Notifications: no streaming connection. See streaming notifications.
- Stored IDs and sync states: converted or rebuilt per customer at the switch. See item IDs.
- Behavior: meetings, sending, search and item kinds. See what changes when EWS code moves to Microsoft Graph.
The switch happens per customer
Tenants lose EWS at different times: the allow list is required from October 10, 2026, tenants that never set EWSEnabled follow in waves, and an administrator can turn EWS back on until April 1, 2027. A customer whose tenant was switched needs a working build that day. The build that can talk to Graph has to be in customers’ hands before their tenant is switched, and it has to keep working on EWS for the ones that have not been.
On the customer’s side the change is the same whichever approach you take: an administrator grants your application the Microsoft Graph permissions it needs. Put that into your upgrade notes early. Consent in a large organization can take longer than the upgrade.
Autodiscover
Products that find the EWS endpoint through Autodiscover meet one more difference: Exchange Online refuses application-only tokens in Autodiscover. For Exchange Online mailboxes the endpoint is known anyway, so the Graph side can skip Autodiscover and keep it for Exchange Server.
How Sunsetless EWS routes calls
Sunsetless EWS is the third approach. It is a build of the EWS Managed API in which the ExchangeService decides by the host of its URL. Calls to outlook.office365.com and outlook.office.com are translated to Microsoft Graph inside your process. Calls to any other host go out as EWS, unchanged. The list of hosts is a setting, and another setting turns the translation off entirely, which is useful for comparing the two paths in a test.
The ISV license covers one product in any number of customer tenants, and its key is not tied to a tenant. For software vendors has the terms; the compatibility table shows what is covered.