Recommended Free Tools
For an app that accesses Exchange Online, migrating from Exchange Web Services (EWS) to Microsoft Graph means more than swapping endpoints: inventory the EWS operations the app actually uses, map each one to Graph or a documented alternative, redesign authentication and mailbox access, then test the changed behavior before cutover. Microsoft’s current schedule says Exchange Online EWS disablement begins globally in October 2026 and is complete in April 2027; Microsoft warns that roadmap estimates can change. Check Microsoft’s live deprecation page for the latest status.
First, confirm that Graph is the right target
Microsoft recommends Graph for applications that access Exchange Online data, including new applications. The migration overview covers Exchange Online and hybrid deployments, but Microsoft states that Graph is not supported for Exchange on-premises. If the app must call an on-premises Exchange server, Graph is not a direct replacement for that deployment. In a hybrid environment, identify which mailboxes and operations are in Exchange Online and which remain on-premises before choosing an API. See Microsoft’s EWS migration overview and Exchange development guidance.
As an Amazon Associate I earn from qualifying purchases.
Migration sequence
- Set the scope. Record the Exchange deployment and mailbox locations the app needs to support. Decide whether the target is Exchange Online only or a hybrid application with separate handling for on-premises mailboxes.
- Inventory live EWS use. Identify active applications and the EWS operations they call, including less visible background jobs and integrations. Microsoft recommends starting with EWS Usage Reports and provides EWS Analyzer and an AI-assisted migration tutorial to help analyze and refactor apps. Use logs and code inspection to establish which calls and data properties are genuinely required.
- Map each operation and its behavior. Use Microsoft’s EWS-to-Graph API mapping table as a cross-reference, then check that the mapped API returns the data and behavior the app depends on. A listed correspondence is not proof of complete feature or behavioral parity.
- Redesign identity and access. Choose delegated permissions if the app acts for a signed-in user, or application permissions if it runs as itself. Select only the Graph mailbox permissions needed, obtain the required consent, and define which mailboxes the application may access.
- Resolve unsupported capabilities. For each operation without a Graph equivalent, decide whether a supported alternative workflow meets the requirement or whether the app must change. Do not assume an unlisted capability will be added before EWS is disabled.
- Test and stage the cutover. Validate the app’s real mail, calendar, synchronization, notification, and permission scenarios in the target tenant. Stage deployment and rollback around the application’s architecture and operating requirements; Microsoft does not prescribe one universal cutover plan.
Map EWS operations to Graph carefully
Microsoft’s mapping guide lists representative correspondences. Treat these as starting points for implementation, not as a guarantee that every EWS option, response property, or edge case behaves identically.
| EWS operation or pattern | Graph direction listed by Microsoft | What to validate |
|---|---|---|
FindItem |
List messages | Confirm the required filters, sorting, paging, and returned properties. |
GetItem |
Get message | Check which item fields and formats the application consumes. |
CreateItem |
Create message | Verify the required message fields and whether the workflow creates a draft or sends. |
MoveItem |
Move message | Test target-folder behavior and any assumptions about item identifiers. |
SendItem |
Send message or send mail | Match the app’s send workflow and required message content. |
SyncFolderHierarchy |
Mail folder delta | Test how the app detects and applies folder changes. |
SyncFolderItems |
Messages delta | Validate incremental synchronization and the app’s handling of changed or removed items. |
EWS push Subscribe/Unsubscribe |
Create/delete Graph subscription | Graph subscriptions cover push notifications; this is not the same design as polling. |
| EWS pull notifications | Messages delta | Microsoft points to delta queries; replace the polling workflow rather than treating it as a subscription endpoint swap. |
GetUserAvailability and FindAvailableMeetingTimes |
Get free/busy schedule | Check the availability scenario and the calendar-sharing or shared-calendar behavior the app needs. |
ConvertId |
Translate Exchange IDs | Confirm how identifiers are used across the app and its integrations. |
ResolveNames |
List people | Verify that people lookup meets the app’s name-resolution needs. |
GetServerTimeZones |
Get time zone choices | Check that the available choices and app’s time-zone handling fit the workflow. |
The mapping guide covers selected utility, mail, calendar, and groups APIs. For each call, compare required inputs, outputs, permissions, error handling, and workflow effects—not just the operation name. Microsoft’s mapping documentation also identifies calendar-sharing and group-related scenarios.
#1 Best Overall
Change authentication and mailbox permissions
Both EWS and Graph use OAuth 2.0 through the Microsoft identity platform and support delegated and application permission types, but their access models differ. Microsoft’s authentication comparison describes EWS delegated access as having what the user can access and EWS application access as having what EWS can access. Graph offers more granular mailbox permissions, so an app can request mail access without also requesting calendar or contacts access.
Choose the identity model that matches the app
- Delegated access: Use when the app operates in a signed-in user’s context and should be limited by that user’s access.
- Application access: Use when the app runs unattended as itself, such as a background service. Microsoft says Graph has no service accounts for this pattern: the app uses its own identity with client credentials.
Application consent can grant broad access, and administrators can limit an application’s access to specific mailboxes. Plan effective access deliberately: grant only the Graph permissions required, obtain the appropriate consent, and configure mailbox access controls for the intended scope. EWS service-account impersonation does not transfer directly as a Graph design.
Basic authentication is not a bridge to Graph. Microsoft says Graph does not support Basic authentication; Graph applications must use OAuth 2.0.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Check parity gaps before committing to a cutover
Microsoft’s deprecation page distinguishes roadmap items from capabilities that will not be added to Graph. Roadmap entries are targets, not guaranteed delivery dates, and Microsoft says estimates may change. As of the page reviewed on October 4, 2026, the listed roadmap included archive, public-folder and group import/export; in-place archive access; mailbox notes; Exchange Admin API capabilities; sovereign-cloud availability; report-message support; non-draft MIME create/update; user-configuration objects; contact lists and properties; and marking all items in a folder as read. Several items had Q3 or Q4 calendar-year 2026 target estimates. Check the current roadmap and status rather than treating those targets as committed availability.
Capabilities Microsoft says will not be added to Graph
- Generic Public Folder create, read, update, and delete operations: Microsoft lists Public Folder import/export separately as a roadmap item; that does not establish general CRUD support.
- Generic Microsoft 365 Group mailbox folder and item CRUD: Microsoft points instead to supported Graph group conversations, threads, and posts. Group mailbox import/export is a separate roadmap item.
- Generic access to legacy Discovery Mailboxes: Microsoft points to Microsoft Purview eDiscovery APIs and workflows for supported discovery capabilities.
For any uncovered operation, determine whether the requirement can be met by a supported alternative or must be redesigned. The existence of a related API or a roadmap entry does not establish a substitute for an app-specific EWS behavior.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Build tests around the app’s real dependencies
There is no universal EWS-to-Graph test suite or cutover recipe in the cited Microsoft guidance. Derive validation from the inventory and exercise the app in a non-production or controlled target tenant before shifting production traffic.
Quick Recap
Best Value
Rank #4
- Verify each mapped operation with the data fields, folders, calendars, and mailboxes the app actually uses.
- Test delegated and application access separately if the app supports both; confirm that consent and mailbox restrictions produce the intended access.
- Exercise incremental synchronization across normal changes and removals, and validate notification behavior according to the redesigned push or delta workflow.
- Check calendar availability, shared-calendar behavior, ID translation, and people lookup where those are part of the app’s inventory.
- Test unsupported or altered scenarios explicitly, including how the app handles permissions failures, unavailable data, and any workflow moved to another Microsoft service.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Free tools Windows power users keep installed
One-click scans. No signup required.
