Introduction

I have been asked a number of times by connections and in DMs over the last few weeks about Microsoft Graph and Azure PowerShell – so I figured I would put together a post on this topic – afterall knowledge sharing is knowledge learned.

Both Microsoft Graph and Azure PowerShell are powerful tools for managing Microsoft cloud services, but they serve different purposes.

Microsoft Graph is the unified REST API that spans across Microsoft 365 services (Azure AD, Teams, Exchange, SharePoint, etc.), while Azure PowerShell refers to the PowerShell modules for managing Azure resources (and previously Azure AD) in a command-line context.

Understanding the differences is important for administrators, especially as Microsoft is moving more functionality to Graph (and deprecating some older Azure PowerShell modules). In this post, I will compare their key differences, see how each can be used in practice, and discuss transitioning from Azure PowerShell (AzureAD/MSOL) to Microsoft Graph.

Comparison Table: Microsoft Graph vs Azure PowerShell

Below is a comparison of key aspects of Microsoft Graph (PowerShell SDK) and Azure PowerShell (specifically the AzureAD PowerShell module for Azure Active Directory tasks, as an example):

Practical Scenario & PowerShell Script Examples

To illustrate the difference in execution, consider a practical scenario:

Creating a new user in Entra ID (Azure AD).

Below are two script snippets that achieve the same goal – one using Microsoft Graph PowerShell and one using the AzureAD PowerShell module. Both will create a new user account, but notice the differences in how they authenticate and the cmdlet syntax:

Using Microsoft Graph PowerShell:

# Connect to Microsoft Graph with the necessary scope (permission) for user management
Connect-MgGraph -Scopes "User.ReadWrite.All"

# Define a password profile for the new user
$passwordProfile = @{ Password = "P@ssw0rd!" }

# Create a new user via Microsoft Graph API (through the Graph PowerShell SDK)
New-MgUser -DisplayName "John Doe" `
           -UserPrincipalName "john.doe@contoso.com" `
           -MailNickname "john.doe" `
           -AccountEnabled $true `
           -PasswordProfile $passwordProfile

# The above commands connect to Microsoft Graph and then create a new Azure AD user named John Doe with the specified UPN and password. 
# Benefit: This uses Microsoft Graph’s up-to-date API, allowing access to the latest Azure AD features and ensuring compatibility with future updates (Graph is the modern approach).

Using Azure PowerShell (AzureAD module):

# Connect to Azure AD using the AzureAD module
Connect-AzureAD

# Prepare a password profile object for the new user (AzureAD module requires a specific object type)
$newUserPassword = New-Object -TypeName Microsoft.Graph.PowerShell.Models.MicrosoftGraphPasswordProfile
$newUserPassword.Password = "P@ssw0rd!"

# Create a new user using AzureAD PowerShell module
New-AzureADUser -DisplayName "John Doe" `
                -UserPrincipalName "john.doe@contoso.com" `
                -MailNickname "john.doe" `
                -AccountEnabled $true `
                -PasswordProfile $newUserPassword

# This connects to Azure AD and creates the same user. 
# Benefit: AzureAD cmdlets are simple and were purpose-built for Azure AD tasks, which made them easy to use for administrators familiar with PowerShell.

Explanation

In the Graph script, we use Connect-MgGraph with an OAuth scope, reflecting Graph’s need for consent to specific permissions. We then call New-MgUser – a Graph cmdlet – to create the user.

In the AzureAD version, we simply do Connect-AzureAD (which uses your account’s credentials) and then New-AzureADUser.

One immediate difference is authentication; Graph encourages a scoped OAuth token (more secure and fine-grained), whereas AzureAD module uses your account context directly. Also, Graph’s cmdlet is part of a broader SDK that can manage more than just users, whereas New-AzureADUser is from a module solely focused on Azure AD.

# Update Note
# Original $newUserPassword in the AzureAD module was:
$newUserPassword = New-Object -TypeName Microsoft.Open.AzureAD.Model.PasswordProfile

# Changed to:
$newUserPassword = New-Object -TypeName Microsoft.Graph.PowerShell.Models.MicrosoftGraphPasswordProfile

# Change Reason:
#Microsoft.Open.AzureAD.Model.PasswordProfile was the part of Azure AD for Graph (Azure AD v2), and Azure AD for Graph (Azure AD v2) is deprecated.

Migration & Best Practices

With Microsoft’s shift toward Graph, many organisations are transitioning from AzureAD/MSOL PowerShell modules to Microsoft Graph PowerShell. In fact, Microsoft Graph PowerShell is the official replacement for the AzureAD and MSOL modules. Here are some key points and best practices for migrating and working across both tools:

• Plan the Migration: Start by identifying all scripts and processes that use the AzureAD or MSOL modules. These legacy modules are deprecated and may run the risk of stopping entirely after the retirement date (30 March, 2025). List out those scripts – for each, there should be an equivalent approach using Microsoft Graph PowerShell SDK (https://tinyurl.com/4rwp8c4y).
• Map Out Equivalent Cmdlets: The Graph PowerShell SDK cmdlet names are different from AzureAD module cmdlets. For example, Get-AzureADUser becomes Get-MgUser, New-AzureADGroup becomes New-MgGroup, etc. Microsoft has provided a migration guide (https://tinyurl.com/2s3p3cyh) to help find Graph equivalents. Update your scripts by replacing old commands with the new Graph commands. Keep in mind that parameters might differ slightly, and Graph cmdlets may require specifying properties or filters to get the same data.
• Modernise Authentication: One of the key differences when migrating is how you handle authentication. The AzureAD module allowed using Azure AD credentials (often with less granular permissions). In Graph, you should use Connect-MgGraph with the appropriate scopes, or set up an app registration for app-only access in automation scenarios. This means possibly updating how your scripts authenticate – e.g., using certificate-based auth for unattended scripts or interactive device login for ad-hoc runs. The benefit is improved security (MSAL and modern auth with token scopes) compared to legacy ADAL-based auth. Ensure your environment is ready for this (you might need to register an Azure AD app and grant it admin-consent for certain Graph scopes).
• Test Thoroughly: Because the output objects and behaviors can differ, test your updated scripts in a non-production environment. For instance, Graph cmdlets might return different default properties than AzureAD cmdlets did. Verify that the new scripts perform the intended tasks (create the users, update the groups, etc.) and that all required data is being handled. Pay attention to any Graph-specific considerations, like throttling limits or required permission consent – adjust your approach if needed (for example, use server-side filtering with Graph where you previously filtered in the script).
• Avoid Mixing Old and New Modules: It’s generally best practice not to import AzureAD/MSOL and the Graph module in the same PowerShell session, as there could be command name conflicts or token conflicts. Migrate in phases if needed (e.g., update all Azure AD user management scripts at once). During a transition period, you might have some scripts on the old module and some on the new, but plan to fully switch to Graph PowerShell going forward to prevent broken scripts when the old modules are finally disabled.
• Use Best Practices in Graph: Take advantage of Graph’s capabilities. For example, use $filter parameters in Graph cmdlets to limit results server-side, use Select-Object -Property (or the -Property parameter in Graph cmdlets) to only return fields you need – this can improve performance. Also, regularly update the Graph PowerShell SDK to the latest version (Update-Module Microsoft.Graph*) so you have the newest cmdlets and fixes. Microsoft is updating Graph PowerShell regularly to close any gaps and add new features.
• Mind the Permissions: Graph PowerShell operates on the principle of least privilege – you need to explicitly grant the permissions your script will use. This is good for security but means one extra step during setup. Make sure to document which Graph API scopes your scripts require (User.ReadWrite.All, etc.) and have an admin consent to them if the script runs non-interactively. This will save you from unexpected authentication prompts or missing permission errors.

In summary, migrating from Azure PowerShell (AzureAD/MSOL) to Microsoft Graph is a necessary step as the old modules retire on 30 March, 2025. Follow the official guidance, test your changes, and take advantage of Graph’s improvements (security, cross-service capability, support for new features). By doing so, you’ll ensure your automation remains reliable and future-proof.

Conclusion

Both Microsoft Graph and Azure PowerShell are important in the library of a cloud administrator – the key is to use the right tool for the right scenario.

Microsoft Graph (with its PowerShell SDK) shines when you need to work across Microsoft 365 services or leverage the latest capabilities in Azure AD/Microsoft Entra, especially as legacy modules are retired.

Azure PowerShell (Az modules and other service-specific modules) remains crucial for Azure infrastructure management and will continue to be used for those scenarios.

As we approach the retirement of older Azure AD PowerShell modules, it’s clear that the future is with Graph for identity and Microsoft 365 tasks. Administrators should plan their transition accordingly – https://tinyurl.com/yrx6hra6, ensuring that scripts are updated and teams are familiar with the new commands. By staying proactive and embracing the newer tools, you’ll ensure a smooth transition with minimal disruption.

Remember, planning ahead and testing your changes are key – with that in place, you can confidently leverage both Graph and PowerShell to manage your environment effectively.