Microsoft Deprecates Graph CLI and Toolkit

Rationalization of Microsoft Graph Developer Tools

On August 29, 2025, Microsoft announced the deprecation of the Microsoft Graph command line interface (CLI) and the Microsoft Graph Toolkit. Full retirement of these components is planned for August 28, 2026. It seems like both decisions are part of an effort to rationalize the portfolio of Microsoft Graph developer tools.

Microsoft suggests that the replacement for the Microsoft Graph CLI is the Microsoft Graph PowerShell SDK. This makes sense to me. Although the Graph PowerShell SDK has its foibles and has experienced some terrible quality problems over recent releases, a new development group recently took over responsibility for the SDK. Hopefully, they will be able to restore the necessary quality and robustness. The most recent release (V2.30) appears to be reasonably stable, including when used with PowerShell V7.4 in a custom Azure Automation runtime environment.

Software Development Bets Often Fail

Development of software tools is a matter of luck. Some take and are wildly successful. Others fail, perhaps slowly, but eventually as interest peters out or users take their interest elsewhere. Microsoft cannot be criticized for implementing different ways to exploit the Graph, but it can be criticized for not seeking consistency and coverage across the Microsoft 365 ecosystem. I’m not unhappy about the deprecation of the Graph CLI or Graph Toolkit. However, it would be nice to see the effort previously expended on these tools devoted to addressing the issues raised in a recent feedback portal request.

The Complaint Against Microsoft

The feedback portal request is simple: inconsistency is rife across Microsoft 365 administrative interfaces. Fourteen years after the launch of Office 365, it’s inconceivable that so many gaps exist in the API coverage for workloads. Microsoft positions the Graph as the great unifying force, but the facts on the ground are that many operations implemented in administrative portals like the Microsoft 365 admin center or the Entra admin center are accomplished using undocumented private APIs.

Tools like the Graph X-Ray and network traces throw some light onto what happens when administrators take actions in portals, but unless an API is documented, developers outside Microsoft take a risk if they attempt to use knowledge gleaned through unofficial sources to automate processes, or even worse, build products to close gaps left by Microsoft in their API coverage.

The complaint is endorsed by many Microsoft MVPs. Its requests are straightforward:

• Surface all administrative portal functionality through the Microsoft Graph. Although I appreciate that it takes time to achieve full production status. It is reasonable to ask for access through a beta endpoint to start.
• Support application permissions for access to data. This request makes eminent sense. There is no good reason for demanding that access tokens have the global administrator role to change a setting.
• Publish a roadmap and timeline when gaps in administrative coverage will be closed. Again, this is reasonable.
• Move endpoints out of beta status in a reasonable timeframe. Many organizations do not trust beta anything. It would be good if Microsoft committed to moving APIs to the V1.0 (production) endpoint in a reasonable time, say within one year after introducing new functionality in a beta version.

You can help by signing into the feedback portal and voting for the proposal. Nothing described above is radical. The requests made in the proposal make perfect sense. I would add the need to ensure consistency across Microsoft 365 for PowerShell modules. It’s unacceptable when major PowerShell modules like Exchange Online and the Microsoft Graph PowerShell SDK clash over assemblies. It’s also unacceptable when modules like the SharePoint management module stay fixed in PowerShell V5.1.

Moving Towards an Ideal Situation

Even in the ever-changing world of the cloud, customers like predictability and reliability. The ideal situation would be to have a release of all Microsoft 365 developer components on a predictable cadence, say every two months. Each release should make progress towards the goal of achieving full coverage of all Microsoft 365 administrative interfaces and include all the major modules (Exchange, SharePoint, Teams, Microsoft Graph PowerShell SDK, Entra ID) in a manner that all modules released on a certain date are guaranteed to work together.

Such an approach is sensible, but it won’t happen because of Microsoft organizational politics. Unless of course sufficient customers protest the current state by upvoting the request in the feedback portal. Two minutes of your time might be enough to help remediate the problem. Is that too much to ask?

---

So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across the Microsoft 365 ecosystem. Subscribe to the Office 365 for IT Pros eBook to receive insights updated monthly into what happens within Microsoft 365, why it happens, and what new features and capabilities mean for your tenant.