What changes when EWS Managed API code moves to Microsoft Graph

How this list was made

We recorded 186 scenarios against one Exchange Online tenant in September and October 2026, each one twice: once through EWS and once through Microsoft Graph v1.0. Every item below is something we saw in those recordings, unless it names Microsoft’s documentation. Microsoft Graph changes, so read each item as true at that time and test what your code depends on.

Sending mail

The sent copy goes to Sent Items

EWS lets the caller choose where the copy of a sent message is saved (SendAndSaveCopy with a folder) or save none (SendOnly). In Graph, sending a draft with send puts the copy in Sent Items. sendMail can skip the copy with saveToSentItems: false, and neither call takes a folder. To file the copy elsewhere, move it after Exchange has saved it, which takes a moment.

Sending returns no ID

Both Graph calls answer 202 with an empty body. Microsoft’s documented way to find the sent message is to create the draft with the header Prefer: IdType="ImmutableId", send it, and read the message by the same ID afterwards. The copy may not be there right away.

Read receipts cannot be suppressed

Marking a message as read through Graph sends the read receipt its sender asked for. EWS has SuppressReadReceipts for that case. We found no Graph switch for it.

Meetings

Attendees are always notified

With EWS an organizer can save, change or delete a meeting without telling anyone (SendInvitationsMode.SendToNone, SendCancellationsMode.SendToNone). Calendar sync code relies on that. Graph sends the invitation, the update or the cancellation whenever the organizer creates a meeting with attendees, changes its time, place, subject, body or attendees, or deletes it. There is no switch. Glen Scales describes workarounds ↗.

Responses take fewer fields

accept, decline, tentativelyAccept and cancel in Graph take a comment and a flag that says whether to send the response. The extra fields of the EWS response objects (Cc, Bcc, sensitivity, receipt requests, the folder for the saved copy) have no place to go.

The change key of a new meeting is stale

Graph saves a meeting first and sends it afterwards, and sending changes the item. The change key you get back from the create call no longer matches on the next read. Code that updates with ConflictResolutionMode.NeverOverwrite right after creating has to read the item again first.

Finding items

Filter and sort order are tied together

When a request has both $filter and $orderby, Microsoft documents three rules: the properties you sort by must also appear in the filter, in the same order, and before any other property. A request that breaks them fails with InefficientFilter. An EWS FindItem with any restriction and any sort order translates only when you add conditions that are always true for the sort properties.

Search cannot be filtered or sorted

An AQS query string becomes $search. Microsoft documents that a search returns at most 1,000 results, sorted by the date the message was sent. In our tests it could not be combined with $filter or $orderby. An EWS call that passes both a query string and a restriction has to be split, or one half evaluated in your own code. For contacts, events and tasks we found no server-side text search at all.

What Graph does not filter or sort

These work in an EWS restriction or sort order and we found no Graph counterpart: the body text, the size, an item class matched by prefix, DisplayTo and DisplayCc, bit masks on extended properties, and sorting by an extended property. The choices are to page through the folder and evaluate them yourself, or to change what the feature does.

Small things that change results

• Sorting by subject: Graph ignores prefixes such as RE: and FW:, EWS sorts by the full subject.
• A filter that only asks whether an extended property exists needs a condition on its value, for example ep/value ne null.
• Binary extended properties cannot be used in a filter.
• Results of $search come without usable change keys and ignore $expand, so reading extended properties takes a second request by ID.

Items that are not mail

In EWS every item is reached the same way. In Graph each kind has its own API, and /messages shows mail only.

• Calendar items, tasks and contact groups do not appear under /messages. Attachments of a meeting are reached through /events.
• Events, contacts and tasks have no move or copy. Moving one means creating it again in the new folder, with a new ID and a new creation time.
• Tasks live in Microsoft To Do. A To Do task has no extended properties, and its progress is a status, so a percent complete of 25 has nowhere to go.
• Contact groups (personal distribution lists) have no API in Graph v1.0. Microsoft’s roadmap lists them as planned.
• A post (IPM.Post) cannot be created; Graph answers ErrorObjectTypeChanged.
• Contacts, events and tasks that lie in Deleted Items are invisible to their own APIs, and the message list shows only messages.
• An attached item with attachments of its own: Graph accepts the request and drops the inner attachments.

Synchronization and notifications

Stored sync states do not carry over

A SyncState from EWS means nothing to Graph. After the switch the application does one full synchronization per folder and stores delta links from then on.

Calendar delta needs a date window

Messages have a delta query per folder. For events, Graph v1.0 documents delta only on a calendar view, a range between two dates, and it returns the occurrences of a series there. SyncFolderItems on a calendar folder has no direct counterpart.

No streaming notifications

EWS pull notifications map to delta queries and push notifications map to Graph subscriptions with a webhook. The streaming connection has no counterpart. See EWS streaming notifications in Microsoft Graph.

Delta reports net changes

Exchange logs every change, and EWS notifications replay them. A delta query compares two states. An item created and deleted between two polls produces nothing. A hard delete shows up as a deletion, where EWS reported a move to Recoverable Items. Delta does not say whether a message is new or changed; you work that out from what you have seen before.

Identifiers and time

• Stored EWS IDs can be converted with translateExchangeIds, up to 1,000 per call. Graph IDs change when an item moves unless you ask for immutable IDs. See EWS item IDs in Microsoft Graph.
• An EWS ID names its mailbox, and Exchange routes by it. Graph wants the mailbox in the address of every request, so the mailbox has to be stored next to the ID.
• Graph returns times to the second, so DateTimePrecision.Milliseconds has no Graph counterpart.
• Graph takes time zones by name. A custom time zone built with TimeZoneInfo.CreateCustomTimeZone, which the EWS Managed API sends as a full definition, is not accepted.
• Graph returns every body as HTML unless the request says Prefer: outlook.body-content-type="text". BodyType.Best in EWS returned text for a plain-text message.

Mailbox settings

• Out of office: Graph does not show whether external replies are allowed (AllowExternalOof), and it keeps no language for the reply text.
• Inbox rules: the conditions WithinDateRange, FromConnectedAccounts, ItemClasses and MessageClassifications and the actions SendSMSAlertToRecipients and ServerReplyWithMessage have no Graph counterpart. A rule update replaces all conditions, exceptions and actions of the rule.
• Delegates: Graph knows the calendar part of a delegate, through calendar permissions. Permissions on Inbox, Tasks, Contacts, Notes and Journal are not there.
• User configuration objects: Graph cannot list or create them today; Microsoft’s roadmap plans them for the end of 2026. Categories and working hours have their own APIs.
• Free/busy of other people is returned at the free/busy level. More detail than that is not shown to an application.

What has no Graph API

Microsoft’s retirement page on Microsoft Learn has a roadmap of the gaps. On the day we checked it, general access to public folders, to Microsoft 365 group mailboxes and to discovery mailboxes was listed as not coming. Access to online archives, and export and import of public folder items, were planned for the last quarter of 2026. The page also says not to expect a capability that is not on the roadmap before EWS is switched off.

If you would rather not handle these yourself

Sunsetless EWS is a build of the EWS Managed API that sends the same calls to Microsoft Graph and handles most of the differences above inside the library: silent meeting changes, copies in other folders, suppressed read receipts, filters Graph does not have, moves of contacts and tasks, streaming notifications. Where Graph has no way at all, it answers with a clear EWS error. The compatibility table lists every operation and every known difference.