The End of EWS: Migrating to Microsoft Graph with Glen Scales [MVP]

The retirement of Exchange Web Services (EWS) marks one of the biggest transitions in Microsoft messaging development in nearly two decades. For organizations still relying on legacy Exchange integrations, migration is no longer optional — it is urgent. In this episode of the m365.fm podcast, Mirko Peters sits down with longtime Exchange developer, Microsoft MVP, blogger, open-source contributor, and messaging expert Glen Scales to discuss the end of EWS, the future of Microsoft Graph, and what developers and organizations need to do right now before Microsoft permanently disables EWS in Exchange Online. With more than twenty years of experience building against Exchange APIs, Glen has lived through nearly every generation of Microsoft messaging development — from CDO and WebDAV to EWS, OAuth, and Microsoft Graph. His blog posts, GitHub repositories, Stack Overflow answers, and Substack articles have helped thousands of developers solve real-world Exchange and Microsoft 365 challenges. This conversation dives deep into API evolution, migration strategies, Graph limitations, mail architecture, authentication, throttling, notifications, synchronization, PowerShell automation, and the changing future of enterprise messaging development.

WHY THE END OF EWS MATTERS

Microsoft will retire Exchange Web Services in Exchange Online beginning in October 2026, with full removal completed in April 2027. That means:

• Applications using EWS against Microsoft 365 will stop working
• Organizations must identify legacy dependencies now
• Vendors and internal development teams need migration plans immediately
• Old synchronization models may need redesigns
• Security and permission models must be modernized

Glen explains that many organizations still do not realize how deeply EWS is embedded inside older enterprise applications, migration tools, CRM systems, provisioning systems, custom workflows, and legacy automation scripts. Some organizations may even discover unknown EWS dependencies years after original developers left the company.

HOW EXCHANGE DEVELOPMENT EVOLVED

One of the most fascinating parts of the episode is Glen’s perspective on the evolution of Exchange development itself. He describes how messaging development once represented some of the most advanced enterprise programming work available. Back in the early Exchange days, APIs like MAPI and EWS offered developers extremely deep access to mailbox data, calendar structures, public folders, and messaging workflows. Over time, Microsoft shifted toward:

• Cloud-first architecture
• REST APIs
• JSON payloads
• OAuth authentication
• Granular permissions
• Security-first development
• Webhook-based integrations
• Microsoft Graph standardization

This transition fundamentally changed how developers build integrations and applications around Microsoft 365 workloads.

WHY MICROSOFT GRAPH IS THE FUTURE

According to Glen, Microsoft Graph represents a major architectural shift compared to EWS. While EWS relied heavily on SOAP and XML, Microsoft Graph uses modern REST APIs and JSON payloads, making development easier, faster, and far more compatible with modern frameworks and open-source tooling. Microsoft Graph also introduces:

• Better OAuth authentication
• Granular permissions
• Improved security boundaries
• Modern SDK support
• Cross-platform development
• Webhook support
• Delta synchronization
• Modern integration patterns

Glen explains that the biggest security issue with EWS is impersonation. In many EWS scenarios, applications receive extremely broad mailbox access, creating significant security risks in modern enterprise environments. Graph changes this by allowing applications to request only the minimum permissions required.

THE BIGGEST CHALLENGE: MIGRATION

The core challenge organizations now face is migration. Glen explains that simple email workloads are relatively easy to migrate from EWS to Graph because feature parity is already strong for common CRUD operations and mail handling. However, more complex workloads become significantly harder:

• Calendar synchronization
• Tasks and To-Do integrations
• Public folder access
• Custom MAPI property usage
• Legacy forms
• Notification architectures
• Synchronization engines
• Enterprise migration tooling

Many older applications were designed around EWS assumptions that no longer exist in Graph.

STREAMING NOTIFICATIONS VS WEBHOOKS

One of the most technical and insightful parts of the discussion focuses on notifications and synchronization. EWS supported:

• Pull notifications
• Push notifications
• Streaming notifications

Graph primarily relies on webhooks. This introduces major architectural changes because organizations now need:

• Public endpoints
• Cloud-accessible infrastructure
• Modern event processing
• Queue-based architectures
• Notification deduplication
• Better retry logic

Glen explains that older EWS streaming notification systems often struggled in cloud environments because mailbox moves could silently break persistent connections. Modern Graph webhooks behave far better in cloud-native architectures.

DELTA QUERIES, THROTTLING, AND SCALE

Another major topic throughout the episode is scalability. Glen discusses:

• Delta queries
• Synchronization patterns
• Pagination
• Mailbox concurrency
• Batch limits
• API throttling
• Large mailbox operations
• Retry handling

According to Glen, Graph throttling is significantly more restrictive than EWS in some scenarios, especially around large-scale mailbox operations and migrations. This means developers need to:

• Design more efficient applications
• Queue operations intelligently
• Reduce unnecessary requests
• Handle retries correctly
• Respect concurrency limitations
• Avoid notification storms

He strongly recommends using Microsoft Graph SDKs because they automatically handle many retry and throttling behaviors. 

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365–6704921/support.