Join our Newsletter — 33% off our NHI Course
Home› Guides› Azure AD Graph and MSOnline Retirement: Migrating Apps…
Guide Identity & Access Management (IAM)

Azure AD Graph and MSOnline Retirement: Migrating Apps and Scripts to Microsoft Graph

← All guides
By NHI Mgmt Group, edited by Lalit Choda Updated 8 November 2026 13 min read
On this page

Microsoft has retired the Azure AD Graph API and the MSOnline and AzureAD PowerShell modules, so any application, vendor integration or admin script that still depends on them is now failing or about to be found failing. The retirements ran through 2025: MSOnline stopped working by late May 2025, Azure AD Graph API calls were blocked from early September 2025 and AzureAD PowerShell scripts stopped from mid-October 2025, according to Microsoft's announcements. In late 2026 the work is mostly clean-up: finding the stragglers, replacing them with Microsoft Graph and the Microsoft Graph PowerShell SDK, and taking the chance to remove the broad, long-lived permissions the old tools encouraged. This guide is for Entra ID administrators, identity engineers and automation owners. It treats the migration as an identity problem as much as a scripting one, because the scripts and apps involved run as service principals and admin accounts with some of the most powerful permissions in a tenant. For the wider tenant baseline see the Entra ID Security Guide; dedicated pages cover the Azure AD Graph API Retirement and the MSOnline and AzureAD PowerShell Retirement individually.

This is an independent guide from NHI Mgmt Group, based on Microsoft's public documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Product features change, so confirm settings against Microsoft's current documentation.

Key takeaways

  • The deadlines have passed. Microsoft's published dates put MSOnline retirement at April to late May 2025, Azure AD Graph blocking from early September 2025 and AzureAD PowerShell failures from mid-October 2025; anything still using them is broken or unsupported.
  • Entra recommendations are the fastest inventory. "Migrate Applications", "Migrate Service Principals" and the MSOnline and AzureAD PowerShell recommendation report real usage, including vendor apps you do not own.
  • Extended access is no longer an escape hatch. Setting blockAzureADGraphAccess to false only mattered during the opt-in period; Microsoft Learn states it does not grant access after retirement.
  • Do not recreate Directory.ReadWrite.All by reflex. Microsoft ranks it second only to Directory.AccessAsUser.All among delegated permissions; use Find-MgGraphCommand to request the narrowest scope per cmdlet.
  • Move unattended scripts to app-only certificate or managed identity auth. Retire admin accounts and stored passwords that ran MSOnline scripts, and give each automation its own service principal with an owner.

What is changing and why

Azure AD Graph (graph.windows.net) was the original directory API for Azure Active Directory. Microsoft Graph (graph.microsoft.com) replaced it as the single API for Microsoft 365 and Entra ID. Microsoft announced the deprecation of Azure AD Graph in 2019, stated it would get no SLA or maintenance beyond security fixes, and put all new features into Microsoft Graph only.

The MSOnline (Connect-MsolService) and AzureAD (Connect-AzureAD) PowerShell modules were built on the older endpoints, including Azure AD Graph. Microsoft deprecated both on 30 March 2024 and named two replacements: the Microsoft Graph PowerShell SDK and Microsoft Entra PowerShell. Its guidance was to migrate MSOnline first, because it retired first.

Retiring componentTypical usersReplacement
Azure AD Graph APILine-of-business apps, older SDK versions, vendor integrations, custom portalsMicrosoft Graph API (v1.0)
MSOnline PowerShell moduleLicensing, user creation, domain and federation scripts, MFA reportingMicrosoft Graph PowerShell SDK or Microsoft Entra PowerShell
AzureAD and AzureADPreview modulesApp registration, group, role and user scripts; runbooksMicrosoft Graph PowerShell SDK or Microsoft Entra PowerShell

Official timeline and current status

Dates below are as stated in Microsoft's own documentation and Entra blog posts, checked on 8 November 2026. Microsoft adjusted several dates during 2025 and said more specific timelines would come through Microsoft 365 Message Center, so check Message Center history for your tenant.

DateEventSource
2019Azure AD Graph deprecation announcedMicrosoft Learn migration overview
30 June 2023End of three-year notice; Azure AD Graph enters retirement cycleMicrosoft Learn migration overview
30 March 2024MSOnline and AzureAD PowerShell deprecatedEntra blog, MSOnline and AzureAD retirement
31 August 2024New apps get 403 from Azure AD Graph unless configured for extended accessMicrosoft Learn authenticationBehaviors
1 February 2025Existing apps must be configured for extended access to keep calling Azure AD GraphMicrosoft Learn authenticationBehaviors
20 January to March 2025Temporary MSOnline outage testsEntra blog, MSOnline and AzureAD retirement
30 March 2025AzureAD PowerShell support endsEntra blog, MSOnline and AzureAD retirement
Early April to late May 2025MSOnline retired; stops working for all tenants by late May 2025Entra blog, MSOnline and AzureAD retirement
Late July to early September 2025One to two Azure AD Graph outage tests of 8 to 24 hoursEntra blog, Azure AD Graph update (27 June 2025)
Early September 2025Apps can no longer use Azure AD Graph APIsEntra blog, Azure AD Graph update
Mid-October 2025AzureAD PowerShell scripts stop workingEntra blog, Azure AD Graph update

The Microsoft Learn pages still show the earlier extended access end dates (30 June 2025 in one place, 31 August 2025 in another). The later Entra blog post is the more recent statement. Either way, all are in the past.

Who and what is affected

  • Custom applications: apps registered in your tenant that request the Azure AD Graph resource, often older apps built with ADAL-era libraries or early SDKs.
  • Vendor and multi-tenant apps: enterprise applications (service principals) from ISVs that called Azure AD Graph on your tenant. You cannot fix their code, but you can find them and press the vendor or remove them.
  • Admin scripts on workstations: licensing, onboarding, offboarding and reporting scripts that start with Connect-MsolService or Connect-AzureAD, frequently run by a Global Administrator account.
  • Scheduled automation: Azure Automation runbooks, scheduled tasks and CI pipelines that ran the old modules with a stored username and password or a client secret. These are non-human identities that are easy to forget. See the Azure RBAC and Service Principals Guide.
  • Third-party tooling: reporting, backup, migration and audit tools that bundled the old modules.

Finding affected systems and identities

Entra recommendations

Microsoft's own usage-based reports are the best starting point.

  • Migrate Applications: apps registered in your tenant, and service principal sign-ins, that use Azure AD Graph.
  • Migrate Service Principals: applications supplied by vendors that use Azure AD Graph in your tenant.
  • Migrate from the retiring MSOnline and AzureAD PowerShell usage to Microsoft Graph PowerShell: covers the last 30 days; the details view shows operations, last request time and number of users.

Find them in the Entra admin centre under Identity > Overview > Recommendations. Microsoft's December 2024 Entra blog post linked from its update includes an example script to export the recommendation reports for tracking.

Sign-in logs

In Sign-in logs, check both the interactive and non-interactive user sign-in tabs and filter Application to Azure Active Directory PowerShell; Microsoft says both MSOnline and AzureAD sessions appear under that name. For Azure AD Graph, filter by resource for Windows Azure Active Directory (resource ID 00000002-0000-0000-c000-000000000000). Microsoft notes that sign-in logs show who acquired a token for Azure AD Graph, not whether API calls succeeded, so treat them as a lead, not proof. See the Entra ID Sign-In and Audit Log Detection Guide for log export and query patterns.

Code and configuration search

  • Repositories: search for graph.windows.net, Connect-MsolService, Connect-AzureAD, Import-Module MSOnline, AzureADPreview and Msol and AzureAD cmdlet prefixes.
  • App registrations: list apps whose requiredResourceAccess includes the Azure AD Graph resource; remove that entry once migrated.
  • Automation accounts and build agents: inventory installed modules and stored credentials used by runbooks and pipelines.

Identities to record for each finding

For every script or app, record the identity it runs as (user, service principal or managed identity), its directory roles, its current API permissions, its credential type and expiry, and a named owner. This list becomes the least-privilege worklist in the next section. The How to find high-privilege Microsoft Graph application permissions walkthrough helps with the permission review.

Migration options

Applications: Azure AD Graph to Microsoft Graph

  1. Replace the Azure AD Graph resource in the app registration's API permissions with the equivalent Microsoft Graph permissions.
  2. Update the code or SDK to call graph.microsoft.com/v1.0; resource shapes and property names differ, so test each call.
  3. Re-consent with an administrator. Microsoft states that only Privileged Role Administrator and Global Administrator can consent to application permissions.
  4. For vendor apps, ask the vendor for its Microsoft Graph version and date. If none exists, plan removal.

Scripts: MSOnline and AzureAD to Microsoft Graph PowerShell

Microsoft publishes a full cmdlet map. Common equivalents:

Legacy cmdletMicrosoft Graph PowerShell cmdlet
Connect-MsolService / Connect-AzureADConnect-MgGraph
Get-MsolUser / Get-AzureADUserGet-MgUser
Get-MsolGroup / Get-AzureADGroupGet-MgGroup
Get-MsolRoleMember / Get-AzureADDirectoryRoleMemberGet-MgDirectoryRoleMember
Get-MsolAccountSku / Get-AzureADSubscribedSkuGet-MgSubscribedSku
Set-AzureADUserLicenseSet-MgUserLicense
Set-AzureADUserPasswordUpdate-MgUser
Get-MsolDomainGet-MgDomain
Get-MsolServicePrincipal / Get-AzureADServicePrincipalGet-MgServicePrincipal
New-AzureADApplicationNew-MgApplication
Get-MsolCompanyInformationGet-MgOrganization

Microsoft warns that parameter names and returned objects often differ, so a rename is rarely enough. Licensing scripts and MFA reports usually need the most rework.

Least-privilege Graph scopes

The old modules effectively ran with whatever the signed-in admin could do. Microsoft Graph PowerShell asks for named permissions, which is the chance to cut access down.

  • Find the minimum per cmdlet: Find-MgGraphCommand shows which permissions a cmdlet or API needs; Find-MgGraphPermission lists permissions in a domain with their type and consent requirement.
  • Prefer delegated for interactive admin work: Microsoft recommends the delegated model whenever it meets the need, because effective access is limited by both the permission and the user's own role.
  • Avoid the top tier: Microsoft names Directory.AccessAsUser.All as the highest-privileged delegated permission, Directory.ReadWrite.All as second and Directory.Read.All as the highest read-only permission, and advises using lesser options. A reporting script needs User.Read.All or GroupMember.Read.All, not Directory.ReadWrite.All.
  • Prefer scoped variants: Application.ReadWrite.OwnedBy lets an app manage only applications it owns, which is narrower than Application.ReadWrite.All.
  • Watch user-write permissions: Microsoft notes that application permission User.ReadWrite.All can update properties of users who hold privileged admin roles.
TaskOver-broad habitNarrower starting point (confirm with Find-MgGraphCommand)
Read users for a reportDirectory.ReadWrite.AllUser.Read.All
Read group membershipDirectory.Read.AllGroupMember.Read.All
Manage the automation's own app registrationsApplication.ReadWrite.AllApplication.ReadWrite.OwnedBy
Read app registrations for reviewApplication.ReadWrite.AllApplication.Read.All

Authentication for unattended scripts

Replace stored admin passwords with app-only authentication. Microsoft documents certificate sign-in with Connect-MgGraph -ClientId <app> -TenantId <tenant> -CertificateThumbprint <thumbprint>, and Get-MgContext shows AuthType as AppOnly. Where scripts run on Azure resources such as Automation, a managed identity removes the stored credential entirely. Avoid client secrets where a certificate or managed identity will do; see the Azure Entra Client Secrets Security Guide.

Decision guidance

  • Microsoft Graph PowerShell SDK or Microsoft Entra PowerShell: the Graph SDK covers all of Microsoft Graph and is the long-term default; Entra PowerShell was released later with cmdlets closer to the AzureAD style, which can shorten rewrites of large AzureAD script libraries. Check its current release status before standardising on it.
  • Delegated or app-only: delegated for scripts an admin runs by hand; app-only with certificate or managed identity for anything scheduled.
  • Small tenants: a handful of scripts; rewrite them directly, run them under a Privileged Identity Management activated role and delete the old modules.
  • Large tenants: track findings per owner, migrate high-privilege automation first, and use a shared module of tested helper functions so teams do not each grant broad permissions.

Testing and rollback

  1. Run old and new side by side where possible. For read-only scripts, compare output from the Graph version against an exported baseline captured before retirement.
  2. Test in a non-production tenant or against test users and groups, especially for licence and password changes.
  3. Start with read scopes, confirm results, then add the single write permission each change step needs.
  4. Check consent and role scope with Get-MgContext before each scheduled run is enabled.
  5. Rollback means rolling back the change, not the module. The old modules no longer work, so keep the previous Graph script version in source control and a documented manual procedure for critical tasks such as onboarding while a fix is made.
  6. Clean up afterwards: remove the Azure AD Graph entry from app registrations, uninstall MSOnline and AzureAD modules from admin workstations and automation hosts, and delete credentials the old scripts used.

Risks of doing nothing

  • Silent business failures: onboarding, licensing and offboarding scripts fail, and leavers keep access because a deprovisioning job broke months ago.
  • Shadow fixes: under pressure, someone grants Directory.ReadWrite.All to a new app with a client secret to get things working, creating a high-value credential attackers seek (ATT&CK T1528 Steal Application Access Token, T1098.001 Additional Cloud Credentials).
  • Orphaned identities: service principals and admin accounts used only by dead scripts keep their roles and credentials with no owner.
  • Vendor exposure: an unmaintained vendor integration that never migrated suggests the vendor is not maintaining its security either.

Detection and measurement

  • Open recommendation items: count of apps and service principals in the three Entra recommendations; target zero.
  • Legacy sign-ins: sign-ins to Azure Active Directory PowerShell or the Azure AD Graph resource in the last 30 days.
  • High-privilege grants added: new grants of Directory.ReadWrite.All, Directory.AccessAsUser.All or RoleManagement permissions since migration began; each needs a ticket.
  • Automation with stored passwords or secrets: count of scheduled jobs not using certificate or managed identity auth.
  • Ownerless service principals: automation identities without a named owner.

Alert in your SIEM on consent to application permissions and on new credentials added to service principals (audit log activities for adding app role assignments and updating application credentials), which is where shortcuts taken during migration show up. Microsoft Graph PowerShell activity itself is PowerShell execution (T1059.001) against the directory, so log who runs it and from where.

Framework mapping

ActivityNIST CSF 2.0NIST SP 800-53 Rev 5ATT&CK v20
Inventory legacy API and module usageID.AM-02CM-8
Replace unsupported componentsPR.PS-02SA-22
Least-privilege Graph permissionsPR.AA-05AC-6T1098.003 Additional Cloud Roles
Own and review automation identitiesPR.AA-01AC-2T1098.001 Additional Cloud Credentials
Monitor consent and credential changesDE.CM-09AU-6T1528

Practitioner checklist

  • All three Entra recommendations have been reviewed and exported, with an owner per item.
  • Repositories and automation hosts have been searched for graph.windows.net, Msol and AzureAD cmdlets.
  • Every migrated script requests named Microsoft Graph scopes chosen with Find-MgGraphCommand.
  • No script or app holds Directory.ReadWrite.All or Directory.AccessAsUser.All without a documented reason.
  • Scheduled jobs use certificate or managed identity auth; stored admin passwords are removed.
  • Azure AD Graph entries are removed from app registrations.
  • Vendor apps still on Azure AD Graph have a vendor commitment or a removal date.
  • MSOnline and AzureAD modules are uninstalled from admin workstations and automation hosts.
  • Alerts exist for application permission consent and new service principal credentials.

Standards and references

Related NHI Mgmt Group resources: Entra ID Security Guide · Entra ID Applications and Consent Guide

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Researched and written by the NHI Mgmt Group editorial team using AI tools, under the editorial direction of Lalit Choda. Facts are drawn from the sources listed on this page and checked by our automated quality process. Last updated 8 November 2026. Spotted an error? Use our contact page.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM and Agentic AI security. nhimg.org