Azure Functions Linux Consumption Retirement to Flex Consumption — when and how should I migrate?
Teams on Azure Functions Linux Consumption need a migration decision card that explains the September 30, 2025 feature freeze, language-version caps, and September 30, 2028 retirement so they can decide when to move to Flex Consumption.
Blockers
- framework/azure-functions-linux-consumption — EOL 2028-09-30
- breaking_change_in: framework/azure-functions-linux-consumption → n/a
- requires_version: framework/azure-functions-flex-consumption → runtime/azure-functions-runtime-4.x
- Lock-in via format/functionappconfig
- requires_version: framework/azure-functions-linux-consumption → n/a
- requires_version: framework/azure-functions-flex-consumption → capability/eventgrid
Who this is for
- serverless
- low-ops
- cost-sensitive
- small-team
- enterprise
- compliance
- real-time
Candidates
Migrate Linux Consumption apps to Flex Consumption now
As of 2026-03-15, Microsoft says Linux Consumption gets no new features after September 30, 2025 and is retired on September 30, 2028, while Flex Consumption is the recommended serverless hosting plan for Azure Functions. Microsoft also says most migrations are straightforward, your code often does not need to change, and the migration creates a new Flex app alongside the existing app so you can test before cutover.
When to choose
Best for serverless + low-ops or cost-sensitive + small-team teams that want to stay on Azure Functions with pay-per-use behavior, can run in a Flex-supported region, and can remediate any compatibility blockers now instead of freezing on an aging platform. Prefer this as of 2026-03-15 when you want faster event-driven scaling, optional always-ready instances, virtual network integration, and a supported path beyond the Linux Consumption retirement.
Tradeoffs
Flex Consumption keeps scale-to-zero billing but changes the operating model. Official docs say Flex is Linux-only, supports one app per plan, scales up to 1,000 instances, supports instance sizes of 512 MB, 2,048 MB, or 4,096 MB, and adds virtual network integration plus optional always-ready instances. Official pricing docs say billing is based on executions, memory provisioned while on-demand instances execute, and any always-ready baseline and execution usage, with a monthly free grant of 250,000 executions and 100,000 GB-s for on-demand meters on paid consumption subscriptions.
Cautions
Do not treat Flex as a drop-in replacement for every Linux Consumption app. Microsoft's migration docs say Flex does not support .NET in-process apps, deployment slots, or blob triggers that use `LogsAndContainerScan`; blob triggers must use `EventGrid`. The migration guide also requires you to check for region support, warns that TLS or `WEBSITE_LOAD_CERTIFICATES` usage blocks compatibility, and says Flex uses `functionAppConfig` plus deprecated-setting replacements instead of several legacy app settings such as `FUNCTIONS_WORKER_RUNTIME`, `FUNCTIONS_EXTENSION_VERSION`, and `WEBSITE_CONTENTSHARE`. Microsoft also says Flex only runs on Functions runtime 4.x and you cannot pin a specific runtime version with `FUNCTIONS_EXTENSION_VERSION`.
Sources
- learn.microsoft.com/en-us/azure/azure-functions/migration/migrate-plan-consumption-to-flex
- learn.microsoft.com/en-us/azure/azure-functions/flex-consumption-plan
- learn.microsoft.com/en-us/azure/azure-functions/functions-scale
- learn.microsoft.com/en-us/azure/azure-functions/functions-app-settings
- learn.microsoft.com/en-us/azure/azure-functions/set-runtime-version
- azure.microsoft.com/en-us/pricing/details/functions/
Stay on Linux Consumption only as a short-term holding pattern while you remove blockers
As of 2026-03-15, Microsoft still lets existing Linux Consumption apps run, but the plan is already in its frozen phase for new features and language support. Official docs state that after September 30, 2025 Linux Consumption gets no new features, the option is removed from Azure portal, Visual Studio, and Visual Studio Code, and the last supported Linux Consumption language versions are .NET 9, Python 3.12, Node.js 22, PowerShell 7.4, and Java 21.
When to choose
Best for serverless + cost-sensitive or small-team + low-ops teams that are blocked today by unsupported region coverage, .NET in-process code, certificate usage, deployment slot dependence, or non-Event-Grid blob triggers and need a controlled remediation window before moving. Use this only when the app can remain stable on the frozen Linux Consumption platform and you have a dated migration plan before September 30, 2028.
Tradeoffs
This is the lowest-effort short-term path because you keep the current app in place and avoid an immediate migration. Official pricing docs still describe Consumption billing as per-second resource consumption and executions, with a monthly free grant of 1 million executions and 400,000 GB-s on paid consumption subscriptions. The tradeoff is that Microsoft has frozen Linux Consumption for new features and newer language versions, so platform drift increases over time.
Cautions
This is not a durable end state. Microsoft says Linux Consumption is retired on September 30, 2028, after which there is no technical support and no new Linux Consumption apps can be created. Do not plan platform or language upgrades that need versions newer than .NET 9, Python 3.12, Node.js 22, PowerShell 7.4, or Java 21, and do not assume portal or IDE creation flows remain available after September 30, 2025.
Move to Azure Functions Premium instead of Flex when Flex removes capabilities you rely on
As of 2026-03-15, Microsoft positions Premium as the Azure Functions option for no cold start, virtual network connectivity, longer runtime durations, and Linux container deployments. Official pricing docs say Premium billing is based on vCPU and memory duration per second, there is no execution charge, and at least one instance must always be allocated.
When to choose
Best for enterprise + real-time or compliance + serverless teams where Linux Consumption retirement forces a move but Flex Consumption is not a fit because you need deployment slots, Linux containers, multiple apps on one plan, or a more predictable always-on baseline. Choose this when preserving operational features matters more than preserving the lowest serverless idle cost.
Tradeoffs
Premium removes several Flex constraints. Microsoft docs say Premium supports always-ready and prewarmed instances to avoid cold starts, virtual network connectivity, Linux container deployments, and up to 3 deployment slots per app, while the hosting comparison says Premium can host up to 100 function apps per plan. The tradeoff is higher baseline spend because one or more instances stay warm and billing is not execution-only.
Cautions
Premium is not the same economics as Flex. Official docs say at least one instance per Premium plan must always be kept warm, and the pricing page says billing is based on allocated core seconds and memory rather than pure execution billing. If you use virtual network integration, Microsoft also requires subnet capacity sized for potential instances.
Try with your AI agent
$ npm install -g pocketlantern $ pocketlantern init # Restart Claude Code, Cursor, or your MCP client, then ask: # "Azure Functions Linux Consumption Retirement to Flex Consumption — when and how should I migrate?"