Navigating the EWS and Azure AD Graph Retirement Timeline

Welcome back to the podcast companion blog! The clock is ticking down to the final retirement dates for Exchange Web Services (EWS) and Azure AD Graph API. If your organization relies on these legacy endpoints, the time to act is now. In this post, we will map out critical deadlines, examine the security and architectural benefits of transitioning, and outline a step-by-step strategy to prioritize your application modernization before support officially ends. To hear a deep dive discussion on these topics, make sure to listen to our related episode: Migrate Exchange Web Services to Microsoft Graph with Glen Scales [MVP].

Why Migrate to Microsoft Graph API

End of EWS and Azure AD Graph

You need to act fast. The end of life for EWS and Azure AD Graph API is coming soon. Microsoft will retire EWS by April 2027. Azure AD Graph API will stop working for apps not enabled for extended access after February 2025. If you delay migration, you risk losing access to important services and facing compressed timelines. Take a look at the risks in the table below:

You want to avoid these risks. Migrating to Microsoft Graph API now gives you more time to plan and test your apps. You can keep your services running smoothly and stay ahead of the end of life deadlines.

Benefits of Microsoft Graph API

Microsoft Graph API offers enhanced functionality and a unified endpoint. You can connect to Microsoft 365, Azure Active Directory, and other services using one API endpoint. This makes development easier and gives you comprehensive functionality. Check out the differences between Microsoft Graph API and legacy APIs:

You get advanced features like delta sync and batching. Microsoft Graph API supports modern authentication and works across many platforms. You can build new apps or upgrade existing ones with graph APIs. Microsoft recommends Microsoft Graph API for all new applications. Azure AD Graph API will not get new features. EWS is being phased out. You want to use Microsoft Graph API to future-proof your apps and take advantage of unified endpoint access.

Security Improvements

Security matters. Microsoft Graph API uses OAuth 2.0 and a strong permissions model. You can choose delegated permissions or application permissions. This lets you control who can access data and how apps interact with Microsoft services. Here’s a quick look at the permissions model:

Applications must submit a valid access token to access protected resources. Access tokens include claims that validate identity and permissions. Both the user and the app permissions are checked for delegated access. Microsoft Graph API protects you from vulnerabilities found in legacy APIs. For example, Exchange Hybrid Privilege Escalation and Azure AD Token Validation Failure allowed attackers to escalate privileges. Microsoft Graph API closes these gaps and keeps your data safe.

You get a secure, unified endpoint with Microsoft Graph API. You can trust your apps and services to stay protected and up to date.

Preparing for Migrating to Microsoft Graph

Getting ready for migrating to Microsoft Graph means you need a clear plan. You want to know exactly what you have, what needs to change, and how to make the switch as smooth as possible. Let’s break down the steps so you can tackle api migration with confidence.

Audit Legacy API Usage

Start by figuring out where your current systems use legacy APIs like EWS and Azure AD Graph. This step helps you see the full picture of your legacy app infrastructure. Here’s how you can audit your dependencies:

1. Use Microsoft’s Graph Migration Analysis Tool to scan your applications. This tool will show you which apps rely on Azure AD Graph APIs.
2. Check Microsoft Entra (formerly Azure AD) for built-in recommendations. These tools help you spot outdated Azure AD Graph API dependencies fast.

You can also use PowerShell to check your current EWS settings:

# Check current EWS settingsGet-OrganizationConfig | Select-Object EwsEnabled, EwsAllowList# Add your app to the AllowListSet-OrganizationConfig -EwsAllowList @{Add="your-app-client-id"}Set-OrganizationConfig -EwsEnabled $true

These commands help you see which apps are using EWS and make changes if needed.

Some tools make this process even easier:

• Immediate Actionability: See usage details for both technical and non-technical team members.
• Export Flexibility: Export your findings to CSV for sharing or further analysis.
• Visualization and Time-Framing: Spot trends and justify your migration investment.
• Direct Line to Stakeholders: Find out which apps and owners are behind EWS calls, so you can work together.

By taking these steps, you get a clear view of where your api migration needs to start.

Identify Affected Apps and Workloads

Once you know where the legacy APIs are in use, you need to find out which apps and workloads will be affected by the migration. This helps you prioritize and plan your next moves. Here’s a simple process to follow:

1. Register a new Azure AD app with only the permissions you need. Get admin consent for these permissions.
2. Use certificate-based authentication for automation tasks. This is more secure than client secrets.
3. Make sure your PowerShell host has the latest Microsoft Graph PowerShell SDK and ExchangeOnlineManagement modules.
4. Run an app-usage workflow to discover which apps use EWS-related permissions.
5. Check sign-in activity and audit logs to see which apps are actively using EWS.
6. Cross-check user license assignments to see which users might be impacted.
7. Sort your apps by recent activity. Focus on the most active ones first.

You can use tools like:

• Microsoft 365 Admin Center (Reports > Usage > Exchange > EWS usage)
• Find-EwsUsage.ps1 script
• Microsoft Graph PowerShell SDK
• ExchangeOnlineManagement modules

This process helps you build a prioritized list. You can focus on high-impact apps and workloads first, making your migration more efficient.

Map EWS and Azure AD Graph Calls to Microsoft Graph

Now it’s time to map your old API calls to their new Microsoft Graph API equivalents. This step is key for a successful migration. Here’s what you should do:

• Reimplement your EWS logic using Microsoft Graph where possible. Use OAuth for better security.
• Take advantage of Microsoft’s migration tools and guidance. These resources include mapping guides and AI-assisted tutorials to help you convert EWS calls to Graph.
• Test and redeploy your apps. Make sure everything works as expected, especially for important features like calendar free/busy, delegate access, and complex mailbox queries.

When you migrate your apps, you’ll notice some important architectural changes. For example, Microsoft Graph uses webhooks instead of the old streaming notifications. This means you’ll need to update how your apps handle notifications and sync data.

Here’s a quick comparison of the two approaches:

You get a unified endpoint with Microsoft Graph. This makes it easier to connect to different Microsoft 365 services. The switch from SOAP to REST also makes api interactions simpler and more modern.

Tip: Microsoft Graph lets you create smarter workflows and automate tasks that used to take a lot of manual work. You can connect to more data and build richer apps.

When planning your migration, remember to:

• Prepare your environment before you start. Set up access controls, backups, monitoring, and compliance policies.
• Focus on high-impact use cases first. Quick wins help build support for the broader migration.
• Run pilot migrations with smaller datasets to test your process.
• Get all stakeholders involved early. This includes IT, security, compliance, and business leaders.
• Set up monitoring from day one. Track performance and usage to catch issues early.

By following these steps, you set yourself up for a smooth transition. Migrating to Microsoft Graph doesn’t have to be overwhelming. With the right approach, you can modernize your systems, improve security, and unlock new possibilities with Microsoft Graph API.

Updating Permissions and Authentication

Moving to Microsoft Graph means you need to rethink how your apps handle permissions and authentication. This step is key for keeping your environment secure and making sure your apps work smoothly with Microsoft 365.

Microsoft Graph Permissions Model

You’ll notice right away that Microsoft Graph uses a different permissions model than EWS or Azure AD Graph. With Microsoft Graph, you can choose between delegated permissions and application permissions. Here’s how they compare:

• The permissions model lets you grant application permissions, so your app can access resources without a signed-in user.
• EWS mostly uses delegated permissions, which means actions happen in the context of a user.
• EWS also has a strong RBAC model with impersonation, but it wasn’t built for application permissions.
• Microsoft Graph gives you more control with application access policies. You can restrict which mailboxes an app can reach, even if it has broad permissions.

Exchange and its RBAC model were not designed with 'application permissions' in mind, creating some challenges. The workaround made it possible to create an Azure AD integrated application and assign the full_access_as_app permission, which allows the app to have full access via EWS to all mailboxes without a signed-in user.

This new model helps you follow the principle of least privilege. You only grant the permissions your app truly needs.

Transition from Legacy Authentication

Switching from legacy authentication to modern authentication is a must. Microsoft Graph relies on OAuth 2.0, which is more secure and supports features like multi-factor authentication (MFA). Here’s a simple plan to help you make the switch:

1. Tell your IT teams and users about the changes. Make sure everyone knows what’s coming.
2. Replace old tools with ones that support OAuth 2.0. Turn on MFA for all accounts.
3. Review your admin consent policies. Set up approval workflows for third-party apps.

You can also update user sign-in preferences and MFA states using Microsoft Graph endpoints. For example:

• To update sign-in preferences:
  PATCH /users/{id | userPrincipalName}/authentication/signInPreferences
• To update MFA state:
  PATCH /me/authentication/requirements
PATCH /users/{id | userPrincipalName}/authentication/requirements

Modern authentication keeps your data safer and helps you meet compliance needs.

Azure AD App Registration for Microsoft Graph

Registering your apps in azure active directory is a big part of the migration. When you register an app, you set up how it will connect to Microsoft Graph and what api permissions it will need. Here are some best practices:

• Pick a clear name, logo, and publisher info for your app.
• Decide who will consent to your app—users or admins.
• Request only the permissions you need.
• Understand the difference between static, dynamic, and incremental consent.
• Plan for multi-tenant scenarios if your app will be used by more than one organization.

Taking these steps in azure active directory helps your apps run smoothly and securely with Microsoft Graph.

Refactor Code for Microsoft Graph

Replace EWS to Graph Calls

You’re ready to roll up your sleeves and start replacing EWS calls with Microsoft Graph API calls. This step is where you’ll see the biggest changes in your code. You want to make sure your apps keep working and take advantage of new features.

Start by mapping out which applications still use EWS and which ones already support Microsoft Graph. Use a dependency mapping strategy to get a clear picture. You can also run a health checker script to assess your Exchange servers and their roles. This helps you spot any hidden dependencies before you begin your migration.

When you plan your migration, think about change management. You’ll need to time your updates and configure allow-listing to keep everything running smoothly. Here’s a quick table to help you organize your approach:

As you refactor, you’ll run into some common challenges. Some workflows need special attention, especially if you work with archive mailboxes or public folders. Advanced delta semantics differ between EWS and Graph, so you may need to rework parts of your code. Creating mail from raw MIME with MAPI extended properties can also require you to rethink your workflows. Here’s a table that highlights these challenges:

You want to test each change as you go. Start with simple email and calendar features, then move on to more complex scenarios. This way, you can catch issues early and keep your migration on track.

Tip: Focus on high-impact features first. Quick wins help you build momentum and show value to your team.

Migrate Azure AD Graph API Integrations

Now, let’s talk about moving your azure ad graph api integrations to Microsoft Graph. This step is important for keeping your identity and directory features up to date. You’ll notice some differences in how the two APIs work, so you need to pay close attention to the details.

First, review your code for any calls to the azure ad graph api. Look for endpoints like https://graph.windows.net. You’ll want to replace these with Microsoft Graph endpoints, such as https://graph.microsoft.com. Here’s a side-by-side example:

You’ll also see changes in how you add, list, or remove group members. The endpoints look a little different, so make sure you update your code to match. Here’s a quick comparison:

When you migrate, remember that Microsoft Graph returns only a subset of properties by default. If you need more data, use the $select query parameter to ask for extra properties. This helps you keep your apps fast and efficient.

You’ll also notice that Microsoft Graph uses the property name id instead of objectId. Some resources, like applications and service principals, support an alternate key called appId. Update your code to use these new property names.

Note: Always test your integration after each change. This helps you catch any issues with permissions, data, or API responses.

Handle Data Model Differences

Handling data model differences is a key part of api migration. You want your apps to work the same—or better—after you switch to Microsoft Graph. The main differences show up in property names, default responses, and how you request data.

In azure ad graph api, every entity has a unique identifier called objectId. In Microsoft Graph, this is now called id. Some entities, like applications and service principals, also have an appId property you can use as an alternate key. Make sure you update your code to use these new names.

Microsoft Graph returns only a default set of properties for many resources. If you need more details, use the $select parameter in your queries. For example, if you want to get a user’s full profile, you can write:

GET https://graph.microsoft.com/v1.0/users?$select=displayName,mail,jobTitle,department

This approach keeps your API calls fast and reduces the amount of data you need to process.

You’ll also see changes in how you manage group memberships. The endpoints are different, so double-check your code. Here’s a quick table to help you compare:

When you handle these differences, you make your migration smoother and your apps more reliable. You also unlock new features and better performance with Microsoft Graph API.

Callout: Take time to document every change you make. Good documentation helps your team understand the new data model and speeds up future updates.

Migrating from ews to microsoft graph and updating your azure ad graph api integrations can feel like a big job. But with a clear plan, careful testing, and attention to detail, you’ll set your organization up for success. You’ll also get the benefits of modern graph apis, improved security, and better graph access to exchange online.

Use Microsoft Graph SDKs

You don’t have to start from scratch when you move your apps to Microsoft Graph. Microsoft Graph SDKs make your life much easier. These SDKs give you a simple way to connect your code to Microsoft 365 services. You can focus on building features instead of worrying about the details of HTTP requests or authentication.

Here’s why you’ll love using Microsoft Graph SDKs:

• You get a clean and easy-to-use interface. The SDKs hide the messy parts of making raw Graph requests. You don’t need to know every detail about the protocol.
• The SDKs handle common problems for you. For example, if you hit throttling limits, the SDKs know how to retry your requests. This means fewer errors and less time fixing issues.
• You can work in your favorite programming language. Microsoft Graph SDKs support .NET, Java, JavaScript, Python, and more. Pick the one that fits your project best.
• The SDKs help you stay up to date. When Microsoft adds new features to Microsoft Graph, the SDKs get updates too. You can use the latest tools without a lot of extra work.

Tip: If you want to build web apps or interactive dashboards, check out the microsoft graph toolkit. It gives you ready-made web components that connect to Microsoft Graph with just a few lines of code.

Let’s look at a quick example. Here’s how you can use the Microsoft Graph .NET SDK to get a list of users:

var users = await graphClient.Users    .Request()    .GetAsync();foreach (var user in users){    Console.WriteLine(user.DisplayName);}

You don’t have to write long blocks of code or handle authentication by yourself. The SDK takes care of it. This saves you time and helps you avoid mistakes.

When you use Microsoft Graph SDKs, you speed up your migration. You also make your apps more reliable and easier to maintain. Your team will thank you for choosing the smart path.

Testing After Migration

You’ve done the heavy lifting. Now, you need to make sure everything works as expected. Testing after migration helps you catch issues before your users do. Let’s walk through how you can build a solid test plan, check your apps, and avoid common mistakes.

Build a Test Plan

Start with a clear test plan. This plan keeps you organized and helps you cover all the important areas. Here’s a simple way to build your plan:

1. List all the applications you migrated to Microsoft Graph.
2. Identify the main features for each app. Think about email, calendar, contacts, or directory access.
3. Write down the expected results for each feature.
4. Set up a test environment that matches your production setup.
5. Assign team members to run the tests and record the results.

Tip: Test both simple and complex scenarios. Don’t forget edge cases, like large mailboxes or special permissions.

Validate Functionality and Performance

You want your apps to work just like before—or even better. To validate functionality and performance, follow these steps:

1. Understand the changes between the old and new api endpoints. Review how your apps used Azure AD Graph and how they now use Microsoft Graph.
2. Check all resources that your apps touch. Look at service principals, users, and groups.
3. Update your code to use the new graph endpoints. Make sure you handle new data formats and response types.
4. Adapt your apps to any changes in data structure. For example, Microsoft Graph uses JSON instead of XML.
5. Run your tests in a safe environment. Try out every feature and see if the results match your expectations.
6. Migrate non-critical systems first. Watch how they perform before moving on to important apps.

You can use webhook notifications to get real-time updates when data changes. Delta query helps you keep your data in sync without extra work. JSON batching lets you combine requests and speed up your apps.

Note: Always monitor performance during testing. Look for slow responses or errors. Fix them before you go live.

Address Common Pitfalls

Testing helps you avoid common pitfalls. Here are some things to watch out for:

• Missing permissions: Double-check that your apps have the right permissions in Microsoft Graph.
• Data mismatches: Make sure your apps handle new property names and formats.
• Throttling: If you send too many requests, Microsoft Graph may slow you down. Use the SDKs to handle retries.
• Notification changes: Webhooks replace old notification methods. Test that your apps receive updates correctly.
• Incomplete migration: Don’t forget to update all api calls. Even one missed call can cause problems.

If you run into trouble, check the logs and error messages. They often point you in the right direction. Keep your team in the loop and share what you learn.

Testing after migration gives you peace of mind. You know your apps work well with Microsoft Graph, and your users stay happy.

Monitor and Optimize Post-Migration

After you finish your migration to Microsoft Graph, you need to keep an eye on your apps and services. Monitoring helps you spot issues early and keeps your system running smoothly. You also want to optimize your setup so you get the most out of the improved ecosystem.

Set Up Monitoring and Alerts

You should set up monitoring tools right away. These tools help you track the health of your graph integrations and alert you if something goes wrong. Use Power BI or Azure Event Hubs to watch real-time activity. You can create dashboards that show how your apps use the graph API. Set alerts for failed requests, slow responses, or unusual spikes in usage. If you see a problem, you can fix it before it affects your users.

Tip: Segment your monitoring by team or department. This way, you can see which groups use the service most and find adoption gaps.

You want to make sure your apps stay compliant with regulatory compliance standards. Monitoring helps you catch issues that could affect your compliance status.

Analyze Usage Metrics

Tracking usage metrics gives you valuable insights. You can build an AI-powered dashboard that connects graph usage to productivity gains. Look at how different teams use the service. Measure adoption rates and see where you can improve. You might notice that some departments use the graph API more than others. This helps you target training or support where it’s needed.

• Track productivity ROI, not just raw usage numbers.
• Segment usage by role or department to find gaps.
• Use real-time monitoring to spot trends quickly.
• Measure gains in efficiency and collaboration.

When you analyze these metrics, you can make smart decisions. You might decide to add new features or adjust permissions to help your users get more from the graph API.

Continuous Improvement

You don’t want to stop after migration. Continuous improvement keeps your apps and services up to date. Set up webhook subscriptions for important endpoints like /users. Use delta queries to capture every change. Run scheduled checks every few hours to catch missed updates. Make sure your subscriptions stay valid and renew them when needed.

• Batch requests for resources that change often.
• Use serverless setups to process data efficiently.
• Check for faults and fix them before they cause trouble.

Callout: Document your monitoring and improvement steps. Good records help your team learn and adapt faster.

By following these steps, you keep your graph integrations strong. You make sure your apps stay reliable and secure. You also help your organization grow with the improved ecosystem that Microsoft Graph offers.

Migrating to microsoft graph gives you a clear path to future-proof applications and unlocks real gains in productivity, security, and modernization. You can follow a structured migration plan—audit, update, refactor, test, and monitor—to keep your service reliable and avoid disruptions. Organizations see faster response times, better data consistency, and more granular permissions after migration. You also get continuous improvements in compliance and employee satisfaction. If you need help, check out these resources:

You can embrace Microsoft Graph as your opportunity to modernize your service and build a secure foundation for the future.

FAQ

How long does it take to migrate from EWS or Azure AD Graph to Microsoft Graph?

Migration time depends on your app’s size and complexity. Simple apps may take days. Large or complex workloads can take weeks. Start with an audit to estimate your timeline.

Do I need to rewrite all my code for Microsoft Graph?

Not always. You can often map legacy API calls to Microsoft Graph equivalents. Some features need refactoring. Use Microsoft Graph SDKs to speed up the process.

What tools help with migration?

You can use Microsoft’s Graph Migration Analysis Tool, PowerShell scripts, and the Microsoft Graph Toolkit. These tools help you audit, map, and test your migration.

Will my users notice any changes after migration?

Most users won’t see changes if you test well. Some advanced features may work differently. Communicate updates to your users to avoid confusion.

How do I handle permissions in Microsoft Graph?

Microsoft Graph uses delegated and application permissions. Grant only what your app needs. Review and update permissions in Azure AD App Registration.

Can I run EWS and Microsoft Graph together during migration?

Yes, you can run both during migration. This lets you test Microsoft Graph while keeping EWS as a backup. Switch fully when you feel confident.

What should I do if I hit throttling limits?

Tip: Use Microsoft Graph SDKs. They handle retries for you. If you see HTTP 429 errors, slow down your requests and follow the Retry-After header.