Microsoft's October 5, 2026 Azure Tools announcement warns that remaining legacy Azure AD Graph access used by old Azure CLI and Azure PowerShell releases will be disabled progressively after October 6, 2026, over a two-month buffer period. An affected release can stop working during that period; it is not a guaranteed extra two months of access. Read Microsoft's notice.
The notice distinguishes this cleanup from Azure AD Graph's general shutdown on July 1, 2025. Temporary access for legacy first-party clients did not make their old releases supported. Current Azure CLI and Azure PowerShell versions are not affected by this specific retirement. Scope of the change.
My recommendation is to verify the software that actually runs important automation, then test the job's behavior on a supported version. Updating an administrator's laptop is not completion evidence for a scheduled production task.
Identify the Implementation, Not Just the Product Name
Azure CLI moved its directory commands to Microsoft Graph in 2.37.0. Azure PowerShell's identity cmdlets made that transition in Az.Resources 5.1.0. These are historical migration boundaries, not recommended versions to install today. Azure CLI migration reference and Azure PowerShell migration reference.
For my inventory, I would record the job owner, execution location, account, executable or module path, loaded version, and the source of the deployment artifact.
That last detail makes remediation repeatable. A manually updated worker is only a temporary improvement if its next rebuild restores the old package from an unchanged image or installation script.
Prioritize the jobs whose failure would interrupt provisioning, access administration, or recovery. Give each one a named owner and a small acceptance test rather than treating the whole estate as a single upgrade ticket.
Check the Active Environment
My proposed verification runs inside the same environment and under the same execution context as the automation. Capture version evidence from the job itself, with credentials and sensitive output excluded.
For PowerShell, I would distinguish installed modules from the module actually supplying the cmdlet in the active session. If multiple versions exist, document why the job loads the intended one and how a newly started session behaves.
Treat a version pin as a design decision that needs an owner. If it cannot be removed immediately, record the dependency that requires it and the action needed to replace that dependency.
Avoid silently switching a shared environment used by unrelated workloads. A dedicated test environment makes it easier to understand the consequences before changing the common runner.
Review Output Contracts as Well as Authentication
The Azure CLI migration guide documents id replacing objectId in directory-object JSON, along with command-argument and behavior changes. The Azure PowerShell guide likewise lists changed object types, property names, and parameters. CLI changes and PowerShell changes.
I would test the values consumed by the next step in the workflow. A command can authenticate successfully while a parser reads a missing property and sends an empty identifier downstream.
Use explicit assertions for important identifiers and expected record counts. Stop the test on a missing or ambiguous value rather than allowing the next operation to guess a target.
For write-capable jobs, use approved nonproduction objects and review the proposed action before executing it. Test failure handling as well as the happy path so the migration does not introduce an unsafe retry or partial-completion behavior.
Find Calls That Bypass the Updated Tool
Microsoft's notice also calls out direct requests to graph.windows.net and the separate AzureAD/MSOnline module migration. Updating Az alone does not migrate those standalone modules or custom HTTP calls. Other legacy callers.
My review would connect each identified caller to a business task and an accountable owner. A repository match without an execution path may be an unused example; an active scheduled task needs a tested replacement.
Do not fix a legacy call by mechanically replacing the hostname. Review the intended operation, permissions, request structure, and response handling against the supported interface before changing the implementation.
Keep the evidence free of access tokens, secret values, and personal directory data. A useful escalation package explains the failing operation and environment without copying sensitive payloads into a ticket.
Define What Closes the Work
For my completion record, I would require the supported artifact to be deployed, the representative job to pass, and the owner to confirm the expected outcome. Also verify that a fresh worker or rebuilt container uses the corrected dependency set.
Keep any emergency response focused on the affected workflow. The retirement warning is not a reason to weaken authentication or grant broad permissions merely to make an error disappear.
These are proposed operational checks, not a claim that I have inspected or upgraded your Azure automation.
Practical Cloud Engineer Takeaway
Locate the runtime that executes each important job.
Record active tool and module versions with their deployment source.
Test identifiers, parsed output, and downstream behavior after upgrading.
Review custom legacy callers and standalone modules separately.
Use safe test objects for write-capable automation.
Verify the corrected configuration survives a fresh deployment.
Who Should Care?
Azure platform teams, identity administrators, and engineers maintaining long-lived automation workers, build images, runbooks, or scheduled administrative scripts.
Bottom Line
The remaining legacy access is being removed progressively, not renewed. Confirm what actually runs, move unsupported dependencies to a supported path, and prove the complete job still produces its intended result.
Sources
Stay radical, stay curious, and keep pushing the boundaries of what is possible in the cloud.
Chriz
Beyond Cloud with Chriz
Comments