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 modernizedGlen 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 standardizationThis 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 patternsGlen 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 toolingMany 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 notificationsGraph 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 lo...
