Migrating from Exchange Web Services (EWS) to Microsoft Graph is often described as a technical exercise: change APIs, update authentication, rewrite a few calls. In reality, it’s something else entirely.
For most tenants, the real challenge is not how to migrate, but discovering how deeply EWS is embedded in existing integrations, applications, and automation.
This article focuses on that reality and shows a simple way to identify applications that still rely on EWS or broad Exchange permissions before you even start migrating.
The Hidden Problem with EWS
EWS rarely exists in isolation.
In many environments, it is used by:
- legacy applications,
- service accounts created years ago,
- third-party tools nobody fully owns anymore,
- scripts that “just work” and were never revisited.
Because EWS lives behind app permissions, it is often invisible in daily operations. Nothing breaks – until Microsoft announces changes or enforcement actions. At that point, the first question usually is:
Which applications in our tenant are actually using EWS?
Why Microsoft Graph Changes the Conversation
Microsoft Graph introduces:
- explicit permission scopes,
- a unified consent model,
- better visibility into application access,
- and stronger alignment with zero-trust principles.
But Graph also forces you to be honest about your environment. You can’t migrate what you don’t know exists. Before rewriting code, the first step should always be inventory.
A Simple Way to Discover EWS Dependencies
The script included below does one very simple thing:
- It connects to Microsoft Graph
- Enumerates all service principals (applications) in the tenant
- Looks for specific high-risk permissions:
That’s it.
No complex logic.
No deep parsing.
Just visibility.
And that visibility is often uncomfortable.
Example Usage
Run the script interactively using an admin account with the required Graph permissions:
|
1 |
Connect-MgGraph -Scopes "Application.Read.All, Directory.Read.All" |
Then execute the script to retrieve all applications that were granted the specified permissions.
The output immediately shows:
- application display name,
- application (client) ID,
- permission scope detected.
In many tenants, this list is longer than expected.
Interpreting the Results
Finding applications with EWS or full access permissions does not automatically mean something is wrong.
But it does mean:
- those applications should be reviewed,
- ownership should be confirmed,
- usage should be validated,
- and migration plans should be discussed.
Typical follow-up questions include:
- Is this app still in use?
- Does it really need EWS?
- Can it be replaced with Microsoft Graph?
- Can permissions be reduced?
The script does not answer these questions – it tells you where to look.
Why This Script Exists
This is not a migration tool.
It’s a discovery tool.
Before migrating from EWS to Microsoft Graph, you need to understand:
- what depends on EWS,
- who owns it,
- and how risky it is to leave it untouched.
This script helps surface that information quickly, using Microsoft Graph itself.
Script Source
Complete script as always is available for download on Azure365Addict GitHub. Feel free to customize the script to fit your specific needs and improve your device management processes.
If you have any questions or want to extend this into automated cleanup or reporting, feel free to reach out.
Happy scripting!
