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 workingOrganizations must identify legacy dependencies nowVendors and internal development teams need migration plans immediatelyOld synchronization models may need redesignsSecurity 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 architectureREST APIsJSON payloadsOAuth authenticationGranular permissionsSecurity-first developmentWebhook-based integrationsMicrosoft 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 authenticationGranular permissionsImproved security boundariesModern SDK supportCross-platform developmentWebhook supportDelta synchronizationModern 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 synchronizationTasks and To-Do integrationsPublic folder accessCustom MAPI property usageLegacy formsNotification architecturesSynchronization enginesEnterprise 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 notificationsPush notificationsStreaming notificationsGraph primarily relies on webhooks. This introduces major architectural changes because organizations now need:Public endpointsCloud-accessible infrastructureModern event processingQueue-based architecturesNotification deduplicationBetter retry logicGlen 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 queriesSynchronization patternsPaginationMailbox concurrencyBatch limitsAPI throttlingLarge mailbox operationsRetry handlingAccording 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 applicationsQueue operations intelligentlyReduce unnecessary requestsHandle retries correctlyRespect concurrency limitationsAvoid notification stormsHe 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.