{"id":25816,"date":"2026-06-11T13:25:22","date_gmt":"2026-06-11T20:25:22","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/microsoft365dev\/?p=25816"},"modified":"2026-06-11T13:25:22","modified_gmt":"2026-06-11T20:25:22","slug":"migrating-ews-notifications-to-microsoft-graph","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/microsoft365dev\/migrating-ews-notifications-to-microsoft-graph\/","title":{"rendered":"Migrating EWS notifications to Microsoft Graph"},"content":{"rendered":"

Migrating from the Exchange Web Services (EWS) notification framework, which supports push, pull, and streaming notification types, to the Microsoft Graph subscription model represents a transition toward a unified, stateless, and event-driven framework. This framework supports more than just Exchange data. Although Microsoft Graph streamlines notifications through webhooks, replacing the varied EWS push, pull, and long-lived connection models requires an architectural redesign. <\/span><\/p>\n

You can migrate your applications by integrating modern Microsoft Graph capabilities like r<\/strong><\/span>ich notifications<\/span><\/b> for reduced latency and i<\/strong><\/span>mmutable IDs<\/span><\/b> for stable item tracking. A successful migration involves moving beyond simple event listening to a hybrid strategy that combines near-real-time change notifications with d<\/strong><\/span>elta queries<\/strong> for reconciliation, while navigating the strict concurrency and availability thresholds of a cloud-native environment.<\/span>\u00a0<\/span><\/p>\n

EWS notifications<\/span><\/b>\u00a0<\/span><\/h2>\n

An application can use three types of EWS notifications, each with different tradeoffs in terms of latency, scalability, and connection management:<\/span>\u00a0<\/span><\/p>\n

    \n
  • Push notifications<\/span><\/b> – Exchange sends an HTTP\/HTTPS request to a listener endpoint hosted by your application whenever an event occurs.<\/span>\u00a0<\/span><\/li>\n<\/ul>\n
      \n
    • Pull notifications<\/span><\/b> – The application periodically calls Exchange to check for new events.<\/span>\u00a0<\/span><\/li>\n<\/ul>\n
        \n
      • Streaming notifications<\/span><\/b> – Establishes a long-lived connection to Exchange (via an HTTP get), allowing the server to push events down to the client as they occur. This eliminates the need for a public endpoint.<\/span>\u00a0<\/span><\/li>\n<\/ul>\n

        Microsoft Graph change notifications<\/span><\/b>\u00a0<\/span><\/h2>\n

        Microsoft Graph only has one type of change notification, which is delivered via webhooks\u2014HTTP POST requests sent to a listener endpoint hosted by your application when a subscribed event occurs. This model enables near real-time updates without the need for constant polling.<\/span>\u00a0<\/span><\/p>\n

        For more advanced scenarios, Microsoft Graph also supports delivering change notifications through Azure Event Hubs. This option is better suited to enterprise-grade applications, and provides enhanced security, scalability, and reliability, particularly in high-throughput or distributed processing environments.<\/span>\u00a0<\/span><\/p>\n

        Microsoft Graph rich notifications<\/span><\/b>\u00a0<\/span><\/h2>\n

        Microsoft Graph rich notifications allow change notifications to include relevant data about the item that triggered the event. For real-time notification scenarios, this data inclusion reduces latency between when an item arrives and when the client is notified, and provides immediate access to key details (such as the subject of a new message and who the sender was).<\/span>\u00a0<\/span><\/p>\n

        Rich notifications simplify certain use cases compared to traditional EWS notifications. For applications where real-time notification is the primary requirement, rich notifications reduce the need for follow-up calls to retrieve item data.<\/span>\u00a0<\/span><\/p>\n

        Pull notifications and change tracking in Microsoft Graph<\/span><\/b>\u00a0<\/span><\/h2>\n

        In EWS, notifications relied on the <\/span>GetEvents<\/span><\/b> operation to retrieve the changes since the last notification. In push and pull notifications, a watermark was available that acted as a subscription marker. In Microsoft Graph, the equivalent capability is provided through delta queries.<\/span>\u00a0<\/span><\/p>\n

        Delta queries enable applications to track changes by requesting only the data that has been added, updated, or deleted since the previous query. Instead of maintaining a connection or polling for events, applications store a\u00a0<\/span>delta token<\/span><\/b> returned by Microsoft Graph and use it in subsequent requests to continue where they left off.<\/span>\u00a0<\/span><\/p>\n

        Microsoft Graph supports delta queries for the following resource types:<\/span>\u00a0<\/span><\/p>\n

          \n
        • Folders:<\/span><\/b>\u00a0Individual Mail, Contact, and Calendar folders.<\/span>\u00a0<\/span><\/li>\n<\/ul>\n
            \n
          • Item collections:<\/span><\/b> Messages, contacts, events, and to do (tasks).<\/span>\u00a0<\/span><\/li>\n<\/ul>\n

            For calendar data, delta queries are supported on both event collections that expose unexpanded recurrence data (where a recurring series is represented as a single master event) and calendar views that return expanded instances of those recurrences (where each occurrence is expanded as an individual event within a specified time range).<\/span><\/p>\n

            Immutable IDs<\/span><\/b>\u00a0<\/span><\/h2>\n

            Microsoft Graph introduces i<\/span>mmutable IDs<\/span><\/b> for mailbox items, a capability that has no direct equivalent in EWS. An immutable ID is a stable, unique identifier for an item \u2014 such as a message, contact, or event \u2014 that remains constant for the lifetime of the item within a mailbox.<\/span>\u00a0<\/span><\/p>\n

            Unlike EWS and Microsoft Graph itemId<\/strong> values, which change when an item is moved between folders, an immutable ID remains unchanged. This means that if an application stores the ID externally, it continues to reference the same item regardless of folder moves within the mailbox.<\/span>\u00a0<\/span><\/p>\n

            Immutable IDs simplify application design compared to EWS. With EWS, developers often needed to track and update externally stored item identifiers after item move operations \u2014 a common use case for notifications. With immutable IDs, that additional tracking logic is unnecessary. As a result, the code is more robust and easier to maintain.<\/span>\u00a0<\/span><\/p>\n

            Note that when items move across mailbox boundaries \u2014 such as between mailboxes or from a mailbox to an archive store \u2014 the immutable ID is invalid because the item is assigned a new ID. If your application needs to track items moved between a mailbox and an archive, consider using a custom extended property instead.<\/span><\/p>\n

            Differences in subscriptions between EWS and Microsoft Graph<\/span><\/b>\u00a0<\/span><\/h2>\n

            In EWS, subscriptions are typically created against a specific mailbox folder or across all folders within a mailbox.<\/span>\u00a0<\/span><\/p>\n

            In Microsoft Graph, change notification subscriptions can be created on specific folder types (such as Inbox or Calendar) or on resource collections such as `<\/span>messages`, `<\/span>contacts`, or `<\/span>events`. However, this model is more constrained than EWS. It supports a reduced set of folder types and doesn’t provide the same level of granularity across all mailbox folders.<\/span>\u00a0<\/span><\/p>\n

            For example, consider an EWS application that uses EWS notifications to subscribe to all mail folders in a mailbox. The application needs to detect when a new email arrives, as well as when an email is moved into a p<\/em><\/span>rocessed<\/span><\/i> folder. With <\/span>Microsoft Graph, the application instead subscribes to the \/messages<\/code> collection to receive notifications for the entire mailbox.<\/span>\u00a0<\/span><\/p>\n

            To track moves, the application monitors created and deleted events and\u00a0checks\u00a0the parentFolderId<\/strong> to determine the item’s location. Because standard item IDs change when a message moves between folders, the application uses immutable IDs to correlate the item\u2019s identity across the mailbox. The application then uses delta queries to reconcile these changes, allowing it to distinguish between newly received messages and moved messages.<\/span>\u00a0<\/span><\/p>\n

            Custom folders gap<\/span><\/b>\u00a0<\/span><\/h2>\n

            Microsoft Graph subscriptions don’t work for all mailbox folders. Custom folders or folders that are typically associated with legacy client features aren’t accessible through the Microsoft Graph messages<\/code>, contacts<\/code>, events<\/code>, or to do<\/code> endpoints. For custom folders, you can either find an alternative solution outside of Exchange or migrate content to a supported endpoint such as messages<\/code>, where webhooks are available.<\/span>\u00a0<\/span><\/p>\n

            Streaming subscription gap<\/span><\/b>\u00a0<\/span><\/h2>\n

            Because Microsoft Graph doesn’t provide an equivalent to the EWS streaming subscription model, applications that use streaming notifications typically require architectural redesign. Instead of maintaining long-lived connections, Microsoft Graph relies on webhook-based notifications, which require a publicly accessible endpoint.<\/span>\u00a0<\/span><\/p>\n

            A common approach is to host the application on a highly available platform that can expose a secure public endpoint, such as Microsoft Azure or a comparable cloud provider. This hosting ensures reliability, scalability, and proper handling of incoming notifications. For any device-based notification (such as mobile or desktop) applications, you can use a backend processing layer that forwards a simplified notification to a mobile push service, such as:<\/span>\u00a0<\/span><\/p>\n