Microsoft announced general availability of PowerShell 7.6 support in Azure Functions on September 21, 2026. Developers can build locally with the new version and deploy to supported Functions plans. Read the GA announcement.
A second announcement on September 23 makes the timing important: PowerShell 7.4 support ends on November 10, 2026. Existing function apps continue to run, but security patches, updates, and support for that version end. Microsoft directs customers to PowerShell 7.6. PowerShell 7.4 retirement notice.
This moves beyond the 7.6 preview previously covered on this blog. My recommendation is to treat it as a scheduled application upgrade, with a separate hosting-plan decision where necessary.
First Identify the Hosting Plan
For Linux Consumption applications, the retirement notice requires migration to Flex Consumption before upgrading to PowerShell 7.6. That prerequisite means some teams have more work than changing the selected language version. Hosting prerequisite.
My first inventory would include the application owner, operating system, hosting plan, language version, triggers, deployment method, and critical dependencies. Group applications by their actual upgrade path rather than treating every PowerShell function as the same task.
Give applications with a plan change an explicit review. Check their deployment, identity, networking, and operational requirements before promising a cutover date. A runtime deadline should not turn an unexamined infrastructure change into an emergency assumption.
Runtime and Language Versions Are Different Settings
Microsoft's upgrade guide distinguishes the Functions runtime version from the language stack version. The FUNCTIONS_EXTENSION_VERSION setting identifies the Functions runtime; it is not the PowerShell version selector. The guide also directs teams to publish application updates before changing the stack configuration. Language-version update guidance.
For a repeatable upgrade, I would capture the current configuration and the intended target in the change record. Have a second engineer review which settings change and why.
Avoid using a successful deployment as the only evidence of a successful upgrade. Record the configured language version and execute a representative function with the intended inputs and identity.
That distinction is especially useful when a deployment pipeline reports success before the application has performed any real work.
Review Script Assumptions and Modules
The PowerShell 7.6 release notes identify Microsoft.PowerShell.ThreadJob as the replacement for the ThreadJob module. The Start-ThreadJob cmdlet is unchanged, but scripts using a module-qualified name need the updated qualifier. The notes also list other breaking changes. PowerShell 7.6 changes.
My proposed review would search the application's scripts and helper modules for version-sensitive assumptions, then test the exact dependency set used by the deployment. Include scripts that run only on a schedule or during error handling.
Do not assume that a developer workstation represents the hosted environment. Use a clean test setup, record the module versions, and verify that the application can load its dependencies without relying on a personal profile or cached login.
If a test fails, change one relevant variable at a time. Updating every dependency at once may be convenient, but it can make the cause of a regression much harder to isolate.
Choose a Test and Rollback Path That the Plan Supports
Microsoft recommends staging slots where supported, but Flex Consumption does not support deployment slots. Its guidance is to validate updated code in a separate nonproduction function app. Changing the stack version also restarts the app. Testing and update considerations.
My recommendation is to write the rollback procedure before the production change. A runbook that says only "swap the slot back" is incomplete if the chosen hosting plan has no slots.
Keep the previous application package and configuration recoverable. Define what symptom triggers rollback, who makes that decision, and how the team confirms that the application has returned to its intended state.
Treat rollback as an incident-recovery option, not permission to remain indefinitely on an unsupported language version. The support deadline still belongs in the completion criteria.
Test the Work, Not Only the Startup
My suggested acceptance test uses the trigger types the application actually relies on and checks the resulting work. For an event-driven function, that might mean confirming the expected downstream record and the handling of a deliberately invalid test event.
Use nonproduction destinations so a test cannot send real customer notifications or change operational data. Check permissions using the intended application identity, and keep sensitive values out of diagnostic output.
Include a repeated-delivery or retry scenario where it is relevant to the application. A clean startup says little about how the function behaves when a dependency times out or the same logical work is presented twice.
Record the evidence in terms the application owner can accept: expected output, error behavior, timing, and operational visibility. These are proposed tests, not results from a deployment I have performed.
Practical Cloud Engineer Takeaway
My proposed checklist is:
Find PowerShell 7.4 applications and assign upgrade owners.
Separate Linux Consumption migrations from language-only changes.
Record Functions runtime and PowerShell stack settings independently.
Review module-qualified calls and test the deployed dependency set.
Use a supported nonproduction testing strategy for the hosting plan.
Rehearse recovery and verify representative application outcomes.
Complete the supported-version move before November 10, 2026.
Who Should Care?
Teams running PowerShell-based Azure Functions for scheduled operations, event processing, integration, or platform automation.
Bottom Line
PowerShell 7.6 GA provides the next supported target. The useful next step is an application-specific upgrade plan that accounts for hosting requirements, dependency behavior, and a tested recovery path before the 7.4 deadline.
Sources
Stay radical, stay curious, and keep pushing the boundaries of what is possible in the cloud.
Chriz
Beyond Cloud with Chriz
Comments