Skip to content

Microsoft Graph or EWS for Outlook calendars after the EWS retirement

Updated

TL;DR

Microsoft is retiring Exchange Web Services in Exchange Online. Tenants that haven't kept it on with an app allow list are switched off from October 1, 2026, and from April 1, 2027 "EWS will be fully and permanently disabled", with "no exceptions past April 2027". Calendar code moves to Microsoft Graph: calendarView and events for reads, getSchedule for free/busy, subscriptions and delta queries for changes. Exchange Server on-premises is not part of this; Microsoft says "EWS is not being retired on-prem."

The dates, in Microsoft's words

Microsoft's Exchange team set the timeline in Exchange Online EWS, Your Time is Almost Up (February 5, 2026):

  • Initial blocking, starting October 1, 2026. "EWS will be disabled by default (EWSEnabled=False) in Exchange Online tenants that have not explicitly chosen to keep it enabled with an AppID Allow List and setting EWSEnabled to True in September 2026."
  • Final EWS shutdown, April 1, 2027. "Starting with April 1, 2027, EWS will be fully and permanently disabled," and "The ability to control EWSEnabled will be removed from tenant admins."
  • No extensions. "There will be no exceptions past April 2027."

Microsoft's deprecation page on Learn, updated October 23, 2026, says the same in short: "October 2026: EWS starts to be disabled globally for all organizations," and "April 2027: EWS is fully disabled."

What October 1 does to a tenant

The switch is the tenant's EWSEnabled setting, which can be True, False or Null, and Null was the default. A tenant still at Null on October 1 "will see the value changed to False as the deployment rolls out," which blocks EWS for every app.

Until April 1, 2027, an administrator can turn it back on in one of two ways:

  • Set EWSEnabled to True and keep an AppID allow list. Only the apps on the list can use EWS.
  • Set EWSEnabled back to Null with Exchange Online PowerShell, which allows all EWS again until the shutdown.

Microsoft pre-populates the allow list for tenants that didn't make one, from each tenant's own usage, and warns that re-enabling after the block means "there will be a service interruption." If your app's Exchange Online calendar access stopped working in October, that is the likely reason, and the fix only buys time until April.

Who is affected

Exchange Online, in every Microsoft cloud. The retirement applies "only to Microsoft 365 and Exchange Online (all environments)." Microsoft widened the scope to its own apps too. After the Midnight Blizzard incident, the Learn page says, "the scope was also widened from third party applications to include all Microsoft applications," with Outlook, Office, Teams and Dynamics 365 named.

Exchange Server on-premises is a different case

Microsoft's own wording is plain. The post says "there are no changes to EWS in Exchange Server," and its FAQ answers the on-premises question directly: "EWS is not being retired on-prem."

Hybrid organizations get both answers at once: "On-prem mailboxes may continue using EWS; cloud mailboxes must move to Graph. Autodiscover will help apps determine mailbox location automatically." Microsoft adds that "only Exchange SE will support Graph for calls to Exchange Online, so hybrid customers will have to use Exchange SE to host on-premises mailboxes."

For an app, that means: if your customers include Exchange Server mailboxes, keep EWS for those and use Graph for Exchange Online, and decide per mailbox.

What moves to Graph for calendars

Microsoft publishes an EWS to Graph mapping. For calendar work it lists:

EWS Microsoft Graph
GetUserAvailability, FindAvailableMeetingTimes Get free/busy schedule (POST /me/calendar/getSchedule)
Subscribe (push notifications) Create subscription
GetReminders Reminder view
ConvertId Translate Exchange IDs
GetServerTimeZones Get time zone choices
Calendar sharing permissions and invitations Share or delegate a calendar

The mapping's item rows (CreateItem, FindItem, UpdateItem, DeleteItem, SyncFolderItems) point to mail messages only. For calendar items, the Graph counterparts are the event endpoints:

Calendar task Microsoft Graph
Read a date range, recurring meetings expanded GET /me/calendarView
List single events and series masters GET /me/events
Track changes in a date range GET /me/calendarView/delta

Check Microsoft's roadmap for parity gaps before you plan. Its rule: "If an EWS capability isn't listed in this roadmap table, don't plan on a corresponding Microsoft Graph or Exchange Admin API capability being available before EWS is fully disabled." The open items are mostly mailbox and admin work, such as import and export, notes and contact lists. None is a calendar event read or write, but two can still matter to a calendar app: folder permissions, which move to the Exchange Admin API, and availability in sovereign clouds.

Differences that bite in a migration

Time zones

Graph returns event times in UTC unless you ask otherwise. "If the Prefer: outlook.timezone header is not specified, the start and end times are returned in UTC." Send the header on every request. See the Node.js guide for the details.

IDs

EWS item IDs and Graph IDs differ. If you stored EWS IDs, convert them with translateExchangeIds rather than matching events by subject and time.

Recurring meetings

/me/events returns series masters, not occurrences. Code that expected an expanded calendar view from EWS should call calendarView.

Change tracking

Delta works per calendar and per date range: "To track the changes in multiple calendars, you need to track each calendar individually," and "$select is not supported." Deleted events come back as "@removed": {"reason": "deleted"}. Save the @odata.deltaLink for the next round.

Throttling

Graph's Outlook limits apply per app per mailbox: 10,000 requests in 10 minutes and four concurrent requests. A migration script that fans out across one mailbox will hit the concurrency limit first.

Moving to Graph does not remove the administrator from the picture. Microsoft's default user consent policy excludes both EWS.AccessAsUser.All and the Graph Calendars.* permissions from what users can approve themselves (source). In a tenant on that default, plan for admin consent either way.

How Pyas handles it

Pyas connects Outlook calendars on Microsoft 365 and Outlook.com, next to Google Calendar, through one API, and it is built on Microsoft Graph, not EWS. It does not connect to on-premises Exchange Server. Pyas renews Graph subscriptions itself, and every event has startsAt in UTC, startsAtLocal and an IANA timezone, whatever Outlook stored. Webhooks for event.created, event.updated and event.deleted name the exact event that changed.

With Pyas Auth, users approve Pyas on Microsoft's own consent screen. Microsoft's default consent policy can still require an administrator to approve calendar access for work accounts, with Pyas Auth too.

Common questions

Can we get an extension past April 2027?

No. Microsoft: "There will be no exceptions past April 2027."

Our EWS calendar sync stopped in October 2026. What happened?

Your tenant's EWSEnabled was probably still Null and was switched to False. An administrator can set it to True with an AppID allow list until April 1, 2027. Use that time to move to Graph.

Does the retirement affect Exchange Server on-premises?

No. Microsoft says "there are no changes to EWS in Exchange Server" and "EWS is not being retired on-prem." In hybrid setups, cloud mailboxes still have to move to Graph.

Is Graph missing anything for calendars?

Not for reading and writing events, by Microsoft's published gap list. Folder permissions and sovereign cloud availability are still on it. Check the list against what your app uses.

How to use the Outlook Calendar API with Microsoft Graph in Node.jsHow to build calendar webhooks that keep working (Google push channels and Microsoft Graph subscriptions)How to fix "Need admin approval" (AADSTS65001, AADSTS90094) for an Outlook calendar app