EWS to Microsoft Graph: What Enterprise Migration Teams Need to Know
Microsoft is changing the way applications interact with Exchange Online.
Exchange Web Services (EWS), which has supported Exchange integrations for many years, is being retired from Exchange Online as Microsoft moves developers and technology providers towards Microsoft Graph. For enterprise migration teams, that change is significant. But supporting a different API is only part of enterprise scale, while managing the volumes, throttling, complexity and data integrity requirements involved in moving years or decades of historical emails.
Why Is Microsoft Moving Away From EWS?
EWS has been a fundamental part of the Exchange ecosystem for many years, allowing applications to access mailbox data and perform a wide range of Exchange operations. However, it was designed for an earlier generation of Exchange integrations.
Microsoft has progressively moved its development focus towards Microsoft Graph, its strategic API platform across Microsoft 365. Graph provides a more modern approach to accessing Microsoft 365 services, aligned with Microsoft’s direction around security, efficiency and cloud-scale application development.
As part of that transition, Microsoft has announced the retirement of EWS in Exchange Online.
For software vendors that rely on EWS to interact with Exchange Online, the change therefore involves more than replacing one API with another. They need a clear transition strategy and technology designed to work effectively within Microsoft’s evolving cloud architecture.
Transvault Has Been Preparing for This for Years
For Transvault, Graph isn’t a last-minute development project. We have spent years preparing for Microsoft’s transition, working closely with Microsoft and actively contributing insight around the requirements of enterprise archive migration.
That distinction matters. Migrating historical enterprise archives introduces requirements that differ from those of everyday mailbox environments. Data volumes can be enormous, historical metadata needs to be preserved, archive mailboxes may behave differently, throttling needs to be managed, unusual and malformed items are encountered, and every migration needs to remain auditable.
These are the realities Transvault has brought to its work around Graph.
API Availability Isn’t the Same as Migration Readiness
When a new API becomes available, developers can begin building against it.
But enterprise readiness requires more. A migration technology needs to demonstrate that the new method behaves correctly against real data and real workloads. That means testing questions such as:
- Can all required data be migrated?
- Is metadata preserved correctly?
- How does the API behave at scale?
- What throttling occurs?
- How should workloads be optimised?
- How are failures reported?
- How are retries handled?
- Are there differences between mailbox types?
- What happens with unusual historical data?
- And can the migration maintain the required Chain of Custody?
Those questions cannot be answered by API documentation alone.
Why We Took the Time to Test
Enterprise customers don’t need a migration technology that simply claims compatibility. They need one they can trust with production data. Transvault’s approach to Graph has therefore focused on extensive development, testing and validation before making broad claims about readiness.
Intelligent Migrator has successfully completed Graph migrations in production environments. That gives us something more valuable than theoretical compatibility: operational experience.
What About EWS Today?
The transition from EWS to Graph is a process rather than a single switch. Migration technologies need to account for Microsoft’s published retirement timetable while also recognising that capabilities have transitioned to Graph at different stages.
The appropriate migration method therefore depends on Microsoft’s available interfaces, the migration scenario and the functionality required.
Intelligent Migrator is designed to evolve through that transition rather than forcing every migration through one technology regardless of suitability.
Graph Changes the Engineering, Not the Migration Standard
The underlying Microsoft technology may be changing, but the standard expected from an enterprise migration should not.
Organisations still need:
- Data integrity
Information should arrive accurately at the destination. - Metadata preservation
Relevant historical context needs to survive the migration. - Performance at scale
Large volumes of data need to be processed efficiently. - Exception visibility
Problematic data needs to be identified and understood. - Auditability
Migration activity needs to be evidenced. - Chain of Custody
Organisations need to know what happened to their data throughout the process.
Those requirements remain regardless of whether the underlying Microsoft interface is EWS, Graph or another migration technology.
Be Careful With “Graph Support”
As more migration vendors announce Graph capabilities, organisations should look beyond the word “supported”. Ask what that support actually means.
- Has the technology been tested against production data?
- Has it completed migrations in production environments?
- At what scale?
- Which Graph interfaces are being used?
- Are any beta interfaces involved?
- What happens where Graph functionality does not yet provide complete parity with previous approaches?
- How is throttling managed?
- How is metadata validated?
- How are exceptions reported?
- And how does the vendor intend to adapt as Microsoft continues developing Graph?
These questions provide a much better picture of migration readiness than a tick in a comparison table.
Microsoft 365 Migration Is an Ongoing Engineering Discipline
Cloud platforms don’t stand still. Microsoft changes APIs, service limits, security requirements and platform capabilities. That means migration technology cannot stand still either.
Transvault Intelligent Migrator has continued to evolve alongside Microsoft’s platform, incorporating new migration technologies while retaining the experience gained from thousands of previous enterprise migrations. Graph is another important stage in that evolution.
Proven Matters More Than First
There is understandable pressure in technology markets to announce support for something new as quickly as possible. But enterprise data migration carries a different responsibility.
When organisations entrust years or decades of historical communications to a migration platform, being first matters far less than knowing the technology can perform reliably at enterprise scale.
Graph support needs to work under real migration conditions: large data volumes, concurrent workloads, Microsoft throttling, complex historical data and the requirement to preserve integrity throughout the process.
For enterprise migration, support for an API is only the starting point. What matters is how that capability performs when put to work.
Preparing for Your EWS-to-Graph Migration Strategy
If your organisation, customer or migration service currently relies on Exchange Online, now is the time to understand what Microsoft’s EWS transition means for future migration projects. Review the technologies your migration tools depend upon.
Ask your migration provider about its Graph roadmap. Understand which Graph capabilities it uses. Ask whether those capabilities have been proven in production.
And make sure migration performance, data integrity and Chain of Custody remain part of the conversation. Because the API may be changing.
The responsibility for your data isn’t.