Table of Contents
Twelve-Month Retirement Period Started as Developers Focus on PowerShell V7
On September 16, 2026, Microsoft did two big things for the Microsoft Graph PowerShell SDK. First, Microsoft announced a twelve-month retirement period to phase out support for Graph SDK modules running on Windows PowerShell 5.1. All future development is centered on PowerShell V7. Second, they released V2.40 of the SDK (available from the PowerShell Gallery).
Microsoft also announced plans to deliver V3 of the Microsoft Graph PowerShell SDK in Q4 of 2026. SDK V3 is targeted at PowerShell V7 and will not include explicit support for Windows PowerShell 5.1. Organizations that wish to continue running Graph SDK scripts on Windows PowerShell 5.1 must remain on a V2 release because V3 will not support the older runtime.
Microsoft emphasizes that the Graph SDK modules will continue to work on Windows PowerShell 5.1 during the retirement period. Announcing twelve months in advance is intended to give customers the chance to move their scripting environment to PowerShell V7.
Following retirement, Graph modules will not stop functioning when invoked by a script running on PowerShell V5.1. However, Microsoft won’t put any effort into supporting issues that occur on the platform. Many organizations run outdated versions of the Graph SDK for different reasons, including avoiding the use of the Web Account Manager (WAM) broker, something that won’t be possible soon for interactive session using the default Microsoft Graph Command Line Tools app.
No Real Surprise
It’s no real surprise that Microsoft should take this action. Making sure that everything works on Windows PowerShell absorbs engineering resources and Microsoft has exhibited a keenness to move away from legacy platforms to focus on newer technology. The move to the new Outlook client is an example that every Microsoft 365 tenant is familiar with.
Removing an email client takes a long time because individual users have built their workflow around how the client operates. The same is true for a PowerShell version, except that the impact is on both individual developers and tenant infrastructures. For example, scripts that run as Azure Automation runbooks in a PowerShell 5.1 runtime environment must be moved to a PowerShell V7 runtime environment. In many cases this won’t be difficult, and I don’t anticipate huge issues with Graph SDK code, but it still needs to be done.
Not the Same as the Azure AD Transition
Experience with large PowerShell transformations inside Microsoft 365 has not demonstrated an expectation that things run as smoothly as anticipated. For example, the move from the Azure AD and Microsoft Online modules to the Graph SDK was first flagged in 2021. The project eventually completed in July 2025. Microsoft had to postpone retirement by a year and introduce a deprecation phase to give customers time to update their scripts. Microsoft even developed the Entra module (based on the Graph SDK) to facilitate the transition.
I don’t expect that the same delays will be experienced in this transition. Graph SDK Cmdlets don’t have to be replaced, and code doesn’t have to be rewritten to take account of new parameters or inputs. Problems are more likely with outdated .NET assemblies that aren’t supported by PowerShell V7. Microsoft’s own struggles to keep .NET assemblies aligned across Microsoft 365 PowerShell modules is testament to that fact.
Overall, the transition is more likely to be a matter of tracking down all the scripts that run on PowerShell 5.1 today and checking that they run properly on PowerShell V7.
Dump Windows Task Scheduler
One thing I think organizations should do during the transition is to dump Windows task Scheduler for script automation and move to Azure Automation instead. Azure Automation offers better security, identity management, monitoring, and operational resilience than Windows Task Scheduler, especially when managed identities are used.
No one likes extra work to do and the decision to move away from PowerShell 5.1 is likely to be unpopular in some quarters. I understand why Microsoft is making the change and think that it’s the right thing to do. These days, the only reason I ever use PowerShell 5.1 is for an occasional session with the SharePoint Online management module. Now there’s a module that needs some tender loving care.
Need help to write and manage PowerShell scripts for Microsoft 365, including Azure Automation runbooks? Get a copy of the Automating Microsoft 365 with PowerShell eBook, available standalone or as part of the Microsoft 365 for IT Pros eBook bundle.