Azure Automation Drops PowerShell 7.1/7.2 and Python 2.7/3.8 on September 30, 2026: How to Migrate Runbooks Before the Cutoff

Microsoft’s retirement notice for Azure Automation is easy to miss if you are not watching the Azure Updates feed closely, and the deadline is close. Starting October 1, 2026, Azure Automation no longer supports the Python 2.7, Python 3.8, PowerShell 7.1, and PowerShell 7.2 runtime versions. If any of your runbooks still target one of these, this is the week to check, not the week after.

What actually happens after the cutoff

Runbooks running on a retired runtime version do not stop working on October 1. Microsoft’s guidance is specific about what “no longer supported” means in practice: runbooks on retired versions continue to run, but in a reduced-support state. That means no new features, no security updates, no bug fixes, and no performance optimizations for that runtime going forward, and Microsoft has indicated the platform may also limit scaling to a single instance for jobs running on deprecated runtimes. For a runbook doing something low-stakes on a predictable schedule, that might be tolerable for a while. For anything handling credentials, running unattended against production resources, or scaling to handle real load, running indefinitely on a runtime that stopped receiving security patches in October 2026 is not a reasonable long-term position.

Finding out if you’re affected

Open your Automation Account in the Azure portal, go to Process Automation, then Runbooks, and check the runtime version listed against each one. If you are managing automation accounts at scale, it is faster to query this programmatically:

Get-AzAutomationRunbook -AutomationAccountName "your-account" -ResourceGroupName "your-rg" |
  Select-Object Name, RuntimeVersion

Run that against every automation account in every subscription you manage. It is common to find old runbooks on PowerShell 7.1 that were created early in an automation account’s life and never touched again once they worked, exactly the kind of thing this deadline is designed to catch.

Migrating with Runtime Environments

Azure Automation’s newer Runtime Environment feature makes this migration considerably less painful than rewriting runbooks from scratch. The process:

• In your Automation Account, go to Process Automation and select Runtime Environments.
• Create a new runtime environment. Give it a name (letters, numbers, underscores, and dashes only, must start with a letter), set the language to PowerShell, and set the runtime version to 7.4, which is the currently generally available target version for this migration. Review the default Az and Azure CLI packages and add anything else your runbook depends on.
• Open the runbook currently running on 7.1 or 7.2 and select Edit in portal. In the Runtime environment dropdown, select the new environment. Only compatible environments will be listed.
• Review the runbook code for anything specific to the older runtime, then use the Test pane to actually run it before publishing. Do not skip this step, cmdlet behavior and module versions can shift enough between PowerShell 7.1 and 7.4 to change output formatting or break assumptions a script was quietly relying on.
• Once the test output matches what you expect, select Publish to move the updated runbook into production.

The benefit of this approach over a manual rewrite is that you are reassigning the runbook to a new environment and testing it in place, not recreating it, which keeps schedules, webhooks, and linked resources intact through the migration.

Python runbooks

The same retirement applies to Python 2.7 and Python 3.8 runbooks, and the same Runtime Environment mechanism handles the migration, create a new environment set to a supported Python version, reassign the runbook, test, and publish. Python 2.7 in particular has been end of life community-wide for years at this point, any runbook still running on it should be treated as a priority regardless of this specific Azure deadline.

Why this is worth doing before the deadline rather than after

Nothing forces an immediate outage on October 1, which is exactly what makes this the kind of deadline that quietly slips. The actual cost shows up later: a security issue in the old runtime that never gets patched, a scaling limit that only bites during a high-load period nobody anticipated, or simply losing the ability to get support from Microsoft when something does break on a runtime they have already retired. Migrating now, while the runbook still works normally and you have time to test properly, is a small, low-pressure task. Migrating after something breaks on an unsupported runtime is not.

Frequently asked questions

Will my runbook actually stop running on October 1, 2026?
No. Microsoft’s guidance confirms runbooks on retired runtime versions continue to run after the cutoff. What stops is security updates, bug fixes, new features, and full support, and the platform may restrict scaling for jobs on retired runtimes.

Do I have to rewrite my runbook to migrate to a new runtime version?
Usually not entirely. The Runtime Environment feature lets you reassign an existing runbook to a new environment and test it there, which handles most migrations without a full rewrite, though you should still review the code and test it, since minor behavior differences between PowerShell versions can occasionally require small script changes.

What PowerShell version should I migrate to instead of 7.1 or 7.2?
PowerShell 7.4 is the current generally available runtime version target for Azure Automation runbook migrations as of this deadline. Check the Runtime Environments creation screen in your Automation Account for the current full list of supported versions, since Microsoft continues to add newer versions over time.