Azure AD Graph Retirement — when and how should I migrate?

Teams still calling Azure AD Graph need to decide whether any extension path is viable and finish a Microsoft Graph migration before extended access ends and production calls stop working across tenants and clouds as the 2025 retirement phases roll out.

Migrate first-party app registrations to Microsoft Graph now, unless the dependency is abandoned or vendor-owned; only use Entra recommendations to coordinate fragmented ownership.

Blockers

Who this is for

Candidates

Migrate first-party app registrations directly to Microsoft Graph

As of 2026-03-15, Microsoft Learn says you can keep the existing app registration `appId`, but you must move calls from Azure AD Graph to Microsoft Graph, review request and permission differences, and regrant application permissions. Microsoft also recommends staging the auth change by first switching token acquisition from `https://graph.windows.net` to `https://graph.microsoft.com`, then finishing the move from retired ADAL to MSAL.

When to choose

Best for enterprise + compliance teams, or microservices + small-team teams, that own the source code for apps registered in their tenant and need the fastest supported path with the least identity-object churn. Use this when you can test API parity in Graph v1.0, update endpoint and permission mappings, and roll out in stages instead of re-registering the app.

Tradeoffs

You keep the current app registration and can often preserve delegated consent, which reduces tenant-level reconfiguration. The tradeoff is nontrivial migration work around request syntax, resource names, IDs, permissions, and SDK or auth-library changes.

Cautions

Do not assume a simple endpoint swap is enough. Microsoft says delegated permissions granted for Azure AD Graph are implicitly considered granted for Microsoft Graph, but application permissions must be granted again. Production migrations should verify required APIs are generally available in Microsoft Graph v1.0 and should test behavior in a test tenant before rollout.

Sources

Use Microsoft Entra recommendations to drive owner-by-owner and vendor-by-vendor remediation

As of 2026-03-15, Microsoft documents two separate Entra recommendations for this retirement: `aadGraphDeprecationApplication` for apps registered in your tenant and `aadGraphDeprecationServicePrincipal` for apps registered elsewhere but used in your tenant. This is the best operational path when you need a verified inventory, 30-day activity counts, last request dates, and a split workflow for internal developers versus third-party vendors.

When to choose

Best for enterprise + low-ops environments, or compliance + small-team organizations, where many apps and enterprise applications exist and ownership is fragmented. Use this when you need to prioritize by observed usage, send concrete remediation tasks to internal owners, and separately pressure vendors to ship Microsoft Graph-compatible versions.

Tradeoffs

You get a usage-based migration queue instead of guessing from code or portal configuration alone, and Microsoft marks recommendations completed after 30 days with no Azure AD Graph activity. The tradeoff is that recommendation data still leaves you with real follow-up work: internal apps need code changes, and vendor-backed service principals often require software upgrades outside your direct control.

Cautions

Microsoft's FAQ says the email list of affected app IDs only captures apps used in the last 28 days, so do not rely on one email snapshot as your full inventory. For service principals, Microsoft says you will likely need to contact the vendor for a newer version; this is not usually something you can fix entirely inside your tenant.

Sources

Retire, replace, or isolate dead-end Azure AD Graph dependencies instead of chasing an extension

As of 2026-03-15, there is no viable long-term extension strategy. Microsoft Learn still documents the historical `authenticationBehaviors.blockAzureADGraphAccess` switch, but the same Learn page says the setting was only for extended access and that after retirement all apps receive `403 Unauthorized`; the migration FAQ also says any app using Azure AD Graph stops functioning after retirement.

When to choose

Best for small-team + low-ops teams, or enterprise + compliance teams, where some old integration is abandoned, vendor support is missing, or the business value no longer justifies a code migration. Use this when replacement, decommissioning, or temporary isolation is cheaper and safer than rebuilding an obsolete dependency.

Tradeoffs

This avoids spending engineering time on low-value legacy code and forces a clean supported end state on Microsoft Graph or on a replacement product. The tradeoff is functional loss during decommissioning, migration work onto a different integration path, or business coordination if a vendor cannot supply an updated version quickly.

Cautions

Microsoft's official sources conflict on exact cutoff wording: the Microsoft Graph overview says extended access ended on August 31, 2025, the `authenticationBehaviors` page still says extended access was available only until June 30, 2025, and Microsoft's later June 27, 2025 Entra update said apps on extended access stop working starting in early September 2025 with temporary outage tests between late July and early September 2025. Treat that conflict as a reason not to plan around any remaining extension path.

Sources

Facts updated: 2026-03-15
Published: 2026-04-03

Related questions

Try with your AI agent

$ npm install -g pocketlantern
$ pocketlantern init
# Restart Claude Code, Cursor, or your MCP client, then ask:
# "Azure AD Graph Retirement — when and how should I migrate?"
Missing something? Request coverage