Microsoft has set a hard cutoff that could break your serverless workloads without warning: any Azure Functions app still running the version 3.x runtime on a Linux Consumption hosting plan will stop executing entirely after September 30, 2026. It’s not a support deprecation—it’s a forced stop. Separately, the entire Linux Consumption hosting option retires two years later on September 30, 2028, requiring a second migration to the Flex Consumption plan.
The details, spelled out on the official Azure Functions runtime versions page, give teams a clear but tight window to act. Ignoring these dates risks production outages with no grace period.
What Exactly Is Changing
Two independent deadlines are in play, and confusing them could derail your migration plan.
September 30, 2026: v3 runtime hard stop on Linux Consumption. Azure Functions version 3.x has been out of extended support since December 2022, but apps on most hosting configurations kept running—until now. Microsoft explicitly states that function apps “still running the end-of-life v3 runtime on Linux in a Consumption plan stop running after September 30, 2026.” The runtime won’t process events, queues, timers, or HTTP triggers. The execution simply halts.
September 30, 2028: Linux Consumption plan retirement. Even if you’re already on version 4.x, running it on a Linux Consumption plan won’t be possible after this date. The plan itself—the Dynamic SKU on Linux—goes away. Microsoft is steering users toward the newer Flex Consumption plan, which the company describes as the future of serverless hosting on Azure.
The distinction matters because an app on v4 still needs a hosting-plan migration before 2028, but the immediate existential threat is only for v3 apps on Linux Consumption. If you’re on Windows Consumption, you’re not affected by either of these specific dates, though unsupported runtime versions anywhere should still be upgraded.
Who Needs to Worry — and Who Doesn’t
You need to act if your function app checks all three of these boxes:
- Hosting OS: Linux (indicated by
reserved: trueon the App Service plan) - Plan tier: Dynamic (the legacy Consumption SKU)
- FUNCTIONS_EXTENSION_VERSION: targets ~3 (or any v3 value)
If that’s you, stop reading this section and jump to the migration roadmap. If you’re unsure, here’s the quick safety check:
- Open the Azure portal, navigate to your Function App’s Overview blade, and click on the linked App Service plan.
- Look at the Operating System and Pricing tier. If you see “Linux” and “Dynamic,” you’re on Linux Consumption.
- Back in the Function App, go to Configuration → Application settings and find
FUNCTIONS_EXTENSION_VERSION. If it says “~3,” your app is a hard-stop candidate.
Even a well-tested CI/CD pipeline can lull you into a false sense of security. Microsoft warns that apps using v2 or v3 “can still be created and deployed from your CI/CD DevOps pipeline.” A green build or successful deployment does not prove that the effective runtime configuration in Azure is safe. Always confirm directly against the live environment.
If your app is on Linux Consumption but already targeting ~4, you’re safe from the 2026 deadline but must plan for 2028. If you’re on Windows Consumption, you’re outside these specific retirements, but any unsupported runtime should still be in your modernization backlog. Apps on Premium, Dedicated, or Flex Consumption plans are not part of the Linux Consumption shutdown at all.
How We Ended Up Here
The Azure Functions runtime has been marching toward version 4.x for years. Version 2.x and 3.x exited extended support on December 13, 2022. Version 1.x, used only for .NET Framework C# apps, loses support on September 14, 2026. But the Linux Consumption v3 hard stop is unique—it’s an execution cutoff, not just an end-of-support date.
Behind the scenes, Microsoft is retiring the underlying infrastructure that powers Linux Consumption. The company has already stopped adding new language versions to the plan. Python 3.12 is the last supported Python version, Node.js 22 is the last for JavaScript, and PowerShell 7.4 marks the end for PowerShell on Linux Consumption. The message is clear: the platform is winding down, and Flex Consumption is the successor.
Many organizations have legacy Functions apps that were set up and forgotten. Some were created through infrastructure-as-code templates that haven’t been touched in years. The 2026 date is Microsoft’s line in the sand to force a move to a supported, modern runtime on a hosting plan that will actually see future investment.
A Practical Migration Roadmap
This isn’t a simple toggle. Upgrading from v3 to v4 involves code changes, dependency updates, and binding revisions, but the process is well-documented. Here’s how to approach it without causing an outage.
1. Inventory everything. Use Azure Resource Graph or manual checks to list every Function App across your subscriptions. For each, note the hosting OS, plan SKU tier, and the FUNCTIONS_EXTENSION_VERSION setting. This is your definitive list of affected apps. Don’t rely on memory or naming conventions.
2. Classify and prioritize. Separate apps into three buckets:
| App Configuration | Deadline | Action |
|---|---|---|
| Linux + Dynamic + ~3 | Sept 30, 2026 | Upgrade to v4 immediately |
| Linux + Dynamic + ~4 | Sept 30, 2028 | Plan migration to Flex Consumption |
| Windows + Dynamic + any version | N/A | Evaluate runtime support; consider upgrade |
| Any non-Dynamic plan | N/A | Validate runtime support |
3. Upgrade to v4, the right way. Don’t just flip the FUNCTIONS_EXTENSION_VERSION setting to “~4.” That won’t work and can break your app. Follow Microsoft’s language-specific migration guide. Key steps typically include:
- Update your project’s target framework and NuGet packages (for .NET), runtime version (for Node.js, Python, etc.), and binding extensions.
- Modify
host.jsonand local settings to align with v4 requirements. - Test locally using the Azure Functions Core Tools v4.
- Deploy to a staging or test environment and exercise every trigger—especially timers and low-frequency event handlers that might not fire during a quick smoke test.
- Once validated, deploy to production and immediately verify the effective configuration in Azure: re-run your checks to confirm the app now shows Linux, Dynamic, and
FUNCTIONS_EXTENSION_VERSION~4.
4. Prevent regression. Update your pipeline definitions and infrastructure-as-code (ARM, Bicep, Terraform) so a future deployment can’t accidentally overwrite the new settings with old v3 values. Consider adding a policy check that rejects any configuration targeting v2 or v3.
5. Start planning for Flex Consumption. While the 2028 deadline feels distant, the migration isn’t trivial. Flex Consumption offers faster scaling, per-function scaling, and reserved instances—benefits that might improve your architecture now. Review the official migration guide and allocate time to test the new plan’s networking and scale behaviors.
Coming Up Next
September 30, 2026 will arrive sooner than it feels. Microsoft is likely to push reminders through Azure Service Health, but the responsibility to act is yours. After the v3 hard stop passes, the entire Linux Consumption portfolio gets a clear two-year runway to move to Flex Consumption—don’t let the secondary date lull you into complacency.
The cloud retirement cycle is accelerating across Microsoft’s platform, from operating systems to serverless infrastructure. Staying ahead means treating runtime and hosting end-of-life dates as production risks, not just maintenance items. If you haven’t already, start that inventory today.