Azure Functions 1.x Support Ends September 14, 2026 – Your Migration Deadline and Action Plan

Microsoft will end support for Azure Functions runtime version 1.x on September 14, 2026. After that date, any app still pinned to the decade-old runtime will receive no security patches, no bug fixes, and no official support from Microsoft. The runtime won’t necessarily stop processing invocations overnight—but continuing to run a critical production workload on unsupported software is a gamble no enterprise should take.

The clock is now ticking. Whether you manage a single legacy function or a portfolio of dozens, the migration to runtime 4.x is a non-negotiable project that demands immediate attention.

The concrete change: 1.x moves from maintenance mode to end-of-support

Microsoft’s official documentation on Azure Functions runtime versions now displays an unambiguous note next to version 1.x: “Support ends for version 1.x on September 14, 2026. Migrate your apps to version 4.x.” Previously, 1.x sat in a maintenance-mode limbo—supported only for C# apps that required .NET Framework, with no new features. The new declaration turns that limbo into a hard expiration date.

This isn’t just about 1.x. Versions 2.x and 3.x are already out of support, having reached end of extended support on December 13, 2022. The only fully supported runtime today is 4.x. For teams still running on those older versions, the path forward is identical: get to 4.x.

There’s a separate but related deadline for Linux Consumption plan users: function apps still on the end-of-life v3 runtime will stop running entirely after September 30, 2026. Microsoft is retiring the Linux Consumption plan itself on September 30, 2028, and is steering everyone toward the Flex Consumption plan. That’s a different migration, but for shops with v1 apps on Linux Consumption, both deadlines converge into one urgent project.

What it means for you: no security patches, no support, no guarantees

If your organization still has production function apps running on runtime 1.x, the risk isn’t theoretical. After September 14, 2026:

• No security fixes: any vulnerability discovered in the 1.x host, underlying components, or bindings will not be patched.
• No bug fixes: performance regressions, stability issues, or functional breaks caused by platform updates won’t be addressed.
• No official support: opening a support ticket for a 1.x-related issue will likely result in a “please upgrade” response.

Unlike the Azure Computer Vision API retirement—where calls to versions 1.0–3.1 will return errors after September 13, 2026—Microsoft has not published a universal “stop processing” date for Functions 1.x. As the documentation states, “previously supported runtimes can continue operating after end of support.” That means your 1.x apps might keep running, but you’re flying without a safety net. The longer you delay, the harder it becomes to untangle dependencies, find institutional knowledge, and test a modern replacement.

For developers: you’re facing code changes. The migration from 1.x to 4.x is not a simple configuration flip. Microsoft’s official guidance requires you to choose one of two supported language paths—C# or JavaScript—and then update project files, packages, bindings, function signatures, and host configuration. Other languages like Java, TypeScript, or PowerShell are not valid starting points for a 1.x migration; if your v1 app was written in something else, you must follow the C# or JS path based on the actual runtime output.

For IT administrators and DevOps engineers: inventory is your first task. If you’re using infrastructure-as-code (ARM, Bicep, Terraform), CI/CD pipelines, or even portal-configured settings, you need to root out every place where FUNCTIONSEXTENSIONVERSION is pinned to ~1. A simple portal change can be silently overwritten by the next pipeline run, leaving you back on an unsupported runtime without realizing it.

For business decision-makers: the risk window is closing. A migration project started today has roughly 18 months to complete—which, in enterprise planning cycles, is not a lot of time when you account for discovery, development, testing, change approval, and eventual decommissioning.

How we got here: a brief history of Azure Functions runtimes

Azure Functions launched in 2016 with runtime 1.x, built on .NET Framework and tightly coupled to Windows. It served a simple purpose: run small pieces of code in response to events, at scale. As the serverless landscape evolved, Microsoft introduced runtime 2.x in 2018, bringing support for .NET Core and more languages, and enabling cross-platform execution on Linux.

Version 3.x arrived in 2019, building on the .NET Core 3.1 foundation. Then, in 2021, runtime 4.x was released as the next long-term support release, based on .NET 6 (and now .NET 8), with an isolated worker model that decouples function code from the host process. The writing was on the wall for 1.x, which never received modern language updates beyond C# and F#, and never supported Linux.

Despite multiple nudges, many organizations clung to 1.x for legacy apps that were “just working.” The September 14, 2026 date is Microsoft’s final call to action.

What to do now: a practical migration roadmap

You can’t migrate what you don’t know you have. Start with a thorough inventory, not a hasty code change.

1. Inventory every v1 function app

Use the Azure CLI, portal, or your own scripts to list all function apps across all subscriptions and identify those where FUNCTIONSEXTENSIONVERSION equals ~1. A quick CLI script (run in a Bash environment authenticated to your tenant) might look like:

az account list --query "[?state=='Enabled'].id" -o tsv |
while read -r subscription; do
  az functionapp list --subscription "$subscription" \
    --query "[].{resourceGroup:resourceGroup,name:name}" -o tsv |
  while read -r resourceGroup name; do
    version=$(az functionapp config appsettings list \
      --subscription "$subscription" \
      --resource-group "$resourceGroup" \
      --name "$name" \
      --query "[?name=='FUNCTIONSEXTENSIONVERSION'].value | [0]" \
      -o tsv)
    if [ "$version" = "~1" ]; then
      printf "subscription=%s resourceGroup=%s functionApp=%s version=%s
" \
        "$subscription" "$resourceGroup" "$name" "$version"
    fi
  done
done

This gives you a raw list. Enhance it with business metadata: app owner, criticality, function language, and deployment method. Document where each app’s configuration is controlled—portal, ARM template, Bicep file, Terraform, or CI/CD variable.

2. Identify the true source of the runtime pin

A v1 pin in the portal might be a ghost. Search your repositories, pipelines, scripts, and infrastructure definitions for FUNCTIONSEXTENSIONVERSION, ~1, and ~4. Until you’ve found and corrected every instance, you haven’t actually migrated.

3. Choose your language migration path

Microsoft’s version 1.x to version 4.x migration guide dictates that only C# and JavaScript are supported starting points for a v1 app. If you have a function written in TypeScript, you must locate the transpiled JavaScript output and follow the JavaScript migration. For F# or other .NET languages, the C# path applies. Do not attempt to treat a v1 app as a Java or PowerShell migration—those runtimes were never supported in 1.x.

For C# apps, the migration typically involves:

• Retargeting the project to .NET 6/8
  
• Updating NuGet packages to the latest Microsoft.NET.Sdk.Functions and extension packages
  
• Adjusting bindings, triggers, and function signatures
  
• Choosing between the in-process model and the isolated worker model (more on that below)
  
• Testing all triggers and bindings

For JavaScript apps:

• Update the Node.js version to a supported runtime (Node 22 or 24 as of this writing)
  
• Migrate to the v4 programming model, which may require changes to function.json or code structure
  
• Update extension bundles to [4.0.0, 5.0.0) in host.json
  
• Verify that all dependencies work with the new Node version

4. Don’t forget the .NET execution model decision

If you’re migrating a .NET v1 app, you get a second important choice: in-process vs. isolated worker. The in-process model runs your code inside the same process as the Functions host, offering high performance but less isolation. The isolated model runs your code in a separate process, aligning with Microsoft’s long-term direction and the only option for future .NET versions. Plan this decision now rather than discovering later that in-process support is being deprecated.

5. Test triggers, bindings, and integrations

Move to a non-production environment first. Exercise every trigger type, every input and output binding, all managed identities, and any service endpoints. Pay special attention to SDK-based bindings that might have changed between v1 and v4.

6. Update your deployment pipeline

Once the code works, update all infrastructure-as-code definitions, release variables, and CI/CD scripts to set FUNCTIONSEXTENSIONVERSION to ~4. Deploy, then verify that the setting matches in the portal and that a subsequent pipeline run won’t revert it.

7. Decide the fate of every v1 app

For each identified app, make an explicit decision:

Exception decisions should be rare and time-boxed. “It still runs” is not a justification—it’s the status quo that you’re trying to escape.

The outlook beyond 2026

Once you’re on runtime 4.x, you’re on the modern path. You gain access to all current and future language versions, the isolated worker model, Flex Consumption plan, and a steady stream of security patches. The next horizon is September 30, 2028, when the Linux Consumption plan fully retires, but that’s a separate, less urgent migration.

For now, the deadline is September 14, 2026. Every day that passes without an inventory and a plan is a day that makes the eventual scramble harder. Start your discovery this week, assign ownership, and treat your legacy v1 apps not as forgotten utilities but as unsupported liabilities—because that’s exactly what they’ll become.