Migrate apps from Azure Functions version 1.x to version 4.x
Important
Java isn't supported by version 1.x of the Azure Functions runtime. Perhaps you're instead looking to migrate your Java app from version 3.x to version 4.x. If you're migrating a version 1.x function app, select either C# or JavaScript above.
Important
TypeScript isn't supported by version 1.x of the Azure Functions runtime. Perhaps you're instead looking to migrate your TypeScript app from version 3.x to version 4.x. If you're migrating a version 1.x function app, select either C# or JavaScript above.
Important
PowerShell isn't supported by version 1.x of the Azure Functions runtime. Perhaps you're instead looking to migrate your PowerShell app from version 3.x to version 4.x. If you're migrating a version 1.x function app, select either C# or JavaScript above.
Important
Python isn't supported by version 1.x of the Azure Functions runtime. Perhaps you're instead looking to migrate your Python app from version 3.x to version 4.x. If you're migrating a version 1.x function app, select either C# or JavaScript above.
Important
Support will end for version 1.x of the Azure Functions runtime on September 14, 2026. We highly recommend that you migrate your apps to version 4.x by following the instructions in this article.
This article walks you through the process of safely migrating your function app to run on version 4.x of the Functions runtime. Because project migration instructions are language dependent, make sure to choose your development language from the selector at the top of the article.
If you are running version 1.x of the runtime in Azure Stack Hub, see Considerations for Azure Stack Hub first.
Identify function apps to migrate
Use the following PowerShell script to generate a list of function apps in your subscription that currently target version 1.x:
$Subscription = '<YOUR SUBSCRIPTION ID>'
Set-AzContext -Subscription $Subscription | Out-Null
$FunctionApps = Get-AzFunctionApp
$AppInfo = @{}
foreach ($App in $FunctionApps)
{
if ($App.ApplicationSettings["FUNCTIONS_EXTENSION_VERSION"] -like '*1*')
{
$AppInfo.Add($App.Name, $App.ApplicationSettings["FUNCTIONS_EXTENSION_VERSION"])
}
}
$AppInfo
Choose your target .NET version
On version 1.x of the Functions runtime, your C# function app targets .NET Framework.
When you migrate your function app, you have the opportunity to choose the target version of .NET. You can update your C# project to one of the following versions of .NET that are supported by Functions version 4.x:
.NET version | .NET Official Support Policy release type | Functions process model1,2 |
---|---|---|
.NET 8 | LTS (end of support November 10, 2026) | Isolated worker model, In-process model2 |
.NET 6 | LTS (end of support November 12, 2024) | Isolated worker model, In-process model2 |
.NET Framework 4.8 | See policy | Isolated worker model |
1 The isolated worker model supports Long Term Support (LTS) and Standard Term Support (STS) versions of .NET, as well as .NET Framework. The in-process model only supports LTS releases of .NET, ending with .NET 8. For a full feature and functionality comparison between the two models, see Differences between in-process and isolate worker process .NET Azure Functions.
2 Support ends for the in-process model on November 10, 2026. For more information, see this support announcement. For continued full support, you should migrate your apps to the isolated worker model.
Tip
Unless your app depends on a library or API only available to .NET Framework, we recommend updating to .NET 8 on the isolated worker model. Many apps on version 1.x target .NET Framework only because that is what was available when they were created. Additional capabilities are available to more recent versions of .NET, and if your app is not forced to stay on .NET Framework due to a dependency, you should target a more recent version. .NET 8 is the fully released version with the longest support window from .NET.
Although you can choose to instead use the in-process model, this is not recommended if it can be avoided. Support will end for the in-process model on November 10, 2026, so you'll need to move to the isolated worker model before then. Doing so while migrating to version 4.x will decrease the total effort required, and the isolated worker model will give your app additional benefits, including the ability to more easily target future versions of .NET. If you are moving to the isolated worker model, the .NET Upgrade Assistant can also handle many of the necessary code changes for you.
This guide doesn't present specific examples for .NET 6. If you need to target that version, you can adapt the .NET 8 examples.
Prepare for migration
If you haven't already, identify the list of apps that need to be migrated in your current Azure Subscription by using the Azure PowerShell.
Before you migrate an app to version 4.x of the Functions runtime, you should do the following tasks:
- Review the list of behavior changes after version 1.x. Migrating from version 1.x to version 4.x also can affect bindings.
- Complete the steps in Migrate your local project to migrate your local project to version 4.x.
- After migrating your project, fully test the app locally using version 4.x of the Azure Functions Core Tools.
- Update your function app in Azure to the new version. If you need to minimize downtime, consider using a staging slot to test and verify your migrated app in Azure on the new runtime version. You can then deploy your app with the updated version settings to the production slot. For more information, see Update using slots.
- Publish your migrated project to the updated function app.
When you use Visual Studio to publish a version 4.x project to an existing function app at a lower version, you're prompted to let Visual Studio update the function app to version 4.x during deployment. This update uses the same process defined in Update without slots.
Migrate your local project
The following sections describes the updates you must make to your C# project files to be able to run on one of the supported versions of .NET in Functions version 4.x. The updates shown are ones common to most projects. Your project code could require updates not mentioned in this article, especially when using custom NuGet packages.
Migrating a C# function app from version 1.x to version 4.x of the Functions runtime requires you to make changes to your project code. Many of these changes are a result of changes in the C# language and .NET APIs.
Choose the tab that matches your target version of .NET and the desired process model (in-process or isolated worker process).
Tip
If you are moving to an LTS or STS version of .NET using the isolated worker model, the .NET Upgrade Assistant can be used to automatically make many of the changes mentioned in the following sections.
Project file
The following example is a .csproj
project file that runs on version 1.x:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net48</TargetFramework>
<AzureFunctionsVersion>v1</AzureFunctionsVersion>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.NET.Sdk.Functions" Version="1.0.24" />
</ItemGroup>
<ItemGroup>
<Reference Include="Microsoft.CSharp" />
</ItemGroup>
<ItemGroup>
<None Update="host.json">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</None>
<None Update="local.settings.json">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
<CopyToPublishDirectory>Never</CopyToPublishDirectory>
</None>
</ItemGroup>
</Project>
Use one of the following procedures to update this XML file to run in Functions version 4.x:
These steps assume a local C# project, and if your app is instead using C# script (.csx
files), you should convert to the project model before continuing.
The following changes are required in the .csproj
XML project file:
Set the value of
PropertyGroup
.TargetFramework
tonet8.0
.Set the value of
PropertyGroup
.AzureFunctionsVersion
tov4
.Add the following
OutputType
element to thePropertyGroup
:<OutputType>Exe</OutputType>
In the
ItemGroup
.PackageReference
list, replace the package reference toMicrosoft.NET.Sdk.Functions
with the following references:<FrameworkReference Include="Microsoft.AspNetCore.App" /> <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.21.0" /> <PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="1.17.2" /> <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore" Version="1.2.1" /> <PackageReference Include="Microsoft.ApplicationInsights.WorkerService" Version="2.22.0" /> <PackageReference Include="Microsoft.Azure.Functions.Worker.ApplicationInsights" Version="1.2.0" />
Make note of any references to other packages in the
Microsoft.Azure.WebJobs.*
namespaces. You'll replace these packages in a later step.Add the following new
ItemGroup
:<ItemGroup> <Using Include="System.Threading.ExecutionContext" Alias="ExecutionContext"/> </ItemGroup>
After you make these changes, your updated project should look like the following example:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net8.0</TargetFramework>
<AzureFunctionsVersion>v4</AzureFunctionsVersion>
<RootNamespace>My.Namespace</RootNamespace>
<OutputType>Exe</OutputType>
<ImplicitUsings>enable</ImplicitUsings>
<Nullable>enable</Nullable>
</PropertyGroup>
<ItemGroup>
<FrameworkReference Include="Microsoft.AspNetCore.App" />
<PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.21.0" />
<PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="1.17.2" />
<PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore" Version="1.2.1" />
<PackageReference Include="Microsoft.ApplicationInsights.WorkerService" Version="2.22.0" />
<PackageReference Include="Microsoft.Azure.Functions.Worker.ApplicationInsights" Version="1.2.0" />
<!-- Other packages may also be in this list -->
</ItemGroup>
<ItemGroup>
<None Update="host.json">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</None>
<None Update="local.settings.json">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
<CopyToPublishDirectory>Never</CopyToPublishDirectory>
</None>
</ItemGroup>
<ItemGroup>
<Using Include="System.Threading.ExecutionContext" Alias="ExecutionContext"/>
</ItemGroup>
</Project>
Package and namespace changes
Based on the model you are migrating to, you might need to update or change the packages your application references. When you adopt the target packages, you then need to update the namespace of using statements and some types you reference. You can see the effect of these namespace changes on using
statements in the HTTP trigger template examples later in this article.
If you haven't already, update your project to reference the latest stable versions of:
Depending on the triggers and bindings your app uses, your app might need to reference a different set of packages. The following table shows the replacements for some of the most commonly used extensions:
Scenario | Changes to package references |
---|---|
Timer trigger | Add Microsoft.Azure.Functions.Worker.Extensions.Timer |
Storage bindings | ReplaceMicrosoft.Azure.WebJobs.Extensions.Storage with Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs, Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues, and Microsoft.Azure.Functions.Worker.Extensions.Tables |
Blob bindings | Replace references toMicrosoft.Azure.WebJobs.Extensions.Storage.Blobs with the latest version of Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs |
Queue bindings | Replace references toMicrosoft.Azure.WebJobs.Extensions.Storage.Queues with the latest version of Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues |
Table bindings | Replace references toMicrosoft.Azure.WebJobs.Extensions.Tables with the latest version of Microsoft.Azure.Functions.Worker.Extensions.Tables |
Cosmos DB bindings | Replace references toMicrosoft.Azure.WebJobs.Extensions.CosmosDB and/or Microsoft.Azure.WebJobs.Extensions.DocumentDB with the latest version of Microsoft.Azure.Functions.Worker.Extensions.CosmosDB |
Service Bus bindings | Replace references toMicrosoft.Azure.WebJobs.Extensions.ServiceBus with the latest version of Microsoft.Azure.Functions.Worker.Extensions.ServiceBus |
Event Hubs bindings | Replace references toMicrosoft.Azure.WebJobs.Extensions.EventHubs with the latest version of Microsoft.Azure.Functions.Worker.Extensions.EventHubs |
Event Grid bindings | Replace references toMicrosoft.Azure.WebJobs.Extensions.EventGrid with the latest version of Microsoft.Azure.Functions.Worker.Extensions.EventGrid |
SignalR Service bindings | Replace references toMicrosoft.Azure.WebJobs.Extensions.SignalRService with the latest version of Microsoft.Azure.Functions.Worker.Extensions.SignalRService |
Durable Functions | Replace references toMicrosoft.Azure.WebJobs.Extensions.DurableTask with the latest version of Microsoft.Azure.Functions.Worker.Extensions.DurableTask |
Durable Functions (SQL storage provider) |
Replace references toMicrosoft.DurableTask.SqlServer.AzureFunctions with the latest version of Microsoft.Azure.Functions.Worker.Extensions.DurableTask.SqlServer |
Durable Functions (Netherite storage provider) |
Replace references toMicrosoft.Azure.DurableTask.Netherite.AzureFunctions with the latest version of Microsoft.Azure.Functions.Worker.Extensions.DurableTask.Netherite |
SendGrid bindings | Replace references toMicrosoft.Azure.WebJobs.Extensions.SendGrid with the latest version of Microsoft.Azure.Functions.Worker.Extensions.SendGrid |
Kafka bindings | Replace references toMicrosoft.Azure.WebJobs.Extensions.Kafka with the latest version of Microsoft.Azure.Functions.Worker.Extensions.Kafka |
RabbitMQ bindings | Replace references toMicrosoft.Azure.WebJobs.Extensions.RabbitMQ with the latest version of Microsoft.Azure.Functions.Worker.Extensions.RabbitMQ |
Dependency injection and startup config |
Remove references toMicrosoft.Azure.Functions.Extensions (The isolated worker model provides this functionality by default.) |
See Supported bindings for a complete list of extensions to consider, and consult each extension's documentation for full installation instructions for the isolated process model. Be sure to install the latest stable version of any packages you are targeting.
Tip
Any changes to extension versions during this process might require you to update your host.json
file as well. Be sure to read the documentation of each extension that you use.
For example, the Service Bus extension has breaking changes in the structure between versions 4.x and 5.x. For more information, see Azure Service Bus bindings for Azure Functions.
Your isolated worker model application should not reference any packages in the Microsoft.Azure.WebJobs.*
namespaces or Microsoft.Azure.Functions.Extensions
. If you have any remaining references to these, they should be removed.
Tip
Your app might also depend on Azure SDK types, either as part of your triggers and bindings or as a standalone dependency. You should take this opportunity to update these as well. The latest versions of the Functions extensions work with the latest versions of the Azure SDK for .NET, almost all of the packages for which are the form Azure.*
.
The Notification Hubs and Mobile Apps bindings are supported only in version 1.x of the runtime. When upgrading to version 4.x of the runtime, you need to remove these bindings in favor of working with these services directly using their SDKs.
Program.cs file
In most cases, migrating requires you to add the following program.cs file to your project:
using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
var host = new HostBuilder()
.ConfigureFunctionsWebApplication()
.ConfigureServices(services => {
services.AddApplicationInsightsTelemetryWorkerService();
services.ConfigureFunctionsApplicationInsights();
})
.Build();
host.Run();
This example includes ASP.NET Core integration to improve performance and provide a familiar programming model when your app uses HTTP triggers. If you do not intend to use HTTP triggers, you can replace the call to ConfigureFunctionsWebApplication
with a call to ConfigureFunctionsWorkerDefaults
. If you do so, you can remove the reference to Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore
from your project file. However, for the best performance, even for functions with other trigger types, you should keep the FrameworkReference
to ASP.NET Core.
The Program.cs
file will replace any file that has the FunctionsStartup
attribute, which is typically a Startup.cs
file. In places where your FunctionsStartup
code would reference IFunctionsHostBuilder.Services
, you can instead add statements within the .ConfigureServices()
method of the HostBuilder
in your Program.cs
. To learn more about working with Program.cs
, see Start-up and configuration in the isolated worker model guide.
The default Program.cs
examples above include setup of Application Insights integration for the isolated worker model. In your Program.cs
, you must also configure any log filtering that should apply to logs coming from code in your project. In the isolated worker model, the host.json
file only controls events emitted by the Functions host runtime. If you don't configure filtering rules in Program.cs
, you may see differences in the log levels present for various categories in your telemetry.
Although you can register custom configuration sources as part of the HostBuilder
, note that these similarly apply only to code in your project. Trigger and binding configuration is also needed by the platform, and this should be provided through the application settings, Key Vault references, or App Configuration references features.
Once you have moved everything from any existing FunctionsStartup
to the Program.cs
file, you can delete the FunctionsStartup
attribute and the class it was applied to.
host.json file
Settings in the host.json file apply at the function app level, both locally and in Azure. In version 1.x, your host.json file is either empty or it contains some settings that apply to all functions in the function app. For more information, see Host.json v1. If your host.json file has setting values, review the host.json v2 format for any changes.
To run on version 4.x, you must add "version": "2.0"
to the host.json file. You should also consider adding logging
to your configuration, as in the following examples:
{
"version": "2.0",
"logging": {
"applicationInsights": {
"samplingSettings": {
"isEnabled": true,
"excludedTypes": "Request"
},
"enableLiveMetricsFilters": true
}
}
}
The host.json
file only controls logging from the Functions host runtime, and in the isolated worker model, some of these logs come from your application directly, giving you more control. See Managing log levels in the isolated worker model for details on how to filter these logs.
local.settings.json file
The local.settings.json file is only used when running locally. For information, see Local settings file. In version 1.x, the local.settings.json file has only two required values:
{
"IsEncrypted": false,
"Values": {
"AzureWebJobsStorage": "AzureWebJobsStorageConnectionStringValue",
"AzureWebJobsDashboard": "AzureWebJobsStorageConnectionStringValue"
}
}
When you migrate to version 4.x, make sure that your local.settings.json file has at least the following elements:
{
"IsEncrypted": false,
"Values": {
"AzureWebJobsStorage": "AzureWebJobsStorageConnectionStringValue",
"FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated"
}
}
Note
When migrating from running in-process to running in an isolated worker process, you need to change the FUNCTIONS_WORKER_RUNTIME
value to "dotnet-isolated".
Class name changes
Some key classes changed names between version 1.x and version 4.x. These changes are a result either of changes in .NET APIs or in differences between in-process and isolated worker process. The following table indicates key .NET classes used by Functions that could change when migrating:
Version 1.x | .NET 8 |
---|---|
FunctionName (attribute) |
Function (attribute) |
TraceWriter |
ILogger<T> , ILogger |
HttpRequestMessage |
HttpRequestData , HttpRequest (using ASP.NET Core integration) |
HttpResponseMessage |
HttpResponseData , IActionResult (using ASP.NET Core integration) |
There might also be class name differences in bindings. For more information, see the reference articles for the specific bindings.
Other code changes
This section highlights other code changes to consider as you work through the migration. These changes are not needed by all applications, but you should evaluate if any are relevant to your scenarios. Make sure to check Behavior changes after version 1.x for additional changes you might need to make to your project.
JSON serialization
By default, the isolated worker model uses System.Text.Json
for JSON serialization. To customize serializer options or switch to JSON.NET (Newtonsoft.Json
), see these instructions.
Application Insights log levels and filtering
Logs can be sent to Application Insights from both the Functions host runtime and code in your project. The host.json
allows you to configure rules for host logging, but to control logs coming from your code, you'll need to configure filtering rules as part of your Program.cs
. See Managing log levels in the isolated worker model for details on how to filter these logs.
HTTP trigger template
Most of the code changes between version 1.x and version 4.x can be seen in HTTP triggered functions. The HTTP trigger template for version 1.x looks like the following example:
using System.Linq;
using System.Net;
using System.Net.Http;
using System.Threading.Tasks;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.Azure.WebJobs.Host;
namespace Company.Function
{
public static class HttpTriggerCSharp
{
[FunctionName("HttpTriggerCSharp")]
public static async Task<HttpResponseMessage>
Run([HttpTrigger(AuthorizationLevel.AuthLevelValue, "get", "post",
Route = null)]HttpRequestMessage req, TraceWriter log)
{
log.Info("C# HTTP trigger function processed a request.");
// parse query parameter
string name = req.GetQueryNameValuePairs()
.FirstOrDefault(q => string.Compare(q.Key, "name", true) == 0)
.Value;
if (name == null)
{
// Get request body
dynamic data = await req.Content.ReadAsAsync<object>();
name = data?.name;
}
return name == null
? req.CreateResponse(HttpStatusCode.BadRequest,
"Please pass a name on the query string or in the request body")
: req.CreateResponse(HttpStatusCode.OK, "Hello " + name);
}
}
}
In version 4.x, the HTTP trigger template looks like the following example:
using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.Logging;
namespace Company.Function
{
public class HttpTriggerCSharp
{
private readonly ILogger<HttpTriggerCSharp> _logger;
public HttpTriggerCSharp(ILogger<HttpTriggerCSharp> logger)
{
_logger = logger;
}
[Function("HttpTriggerCSharp")]
public IActionResult Run(
[HttpTrigger(AuthorizationLevel.Function, "get")] HttpRequest req)
{
_logger.LogInformation("C# HTTP trigger function processed a request.");
return new OkObjectResult($"Welcome to Azure Functions, {req.Query["name"]}!");
}
}
}
To update your project to Azure Functions 4.x:
Update your local installation of Azure Functions Core Tools to version 4.x.
Move to one of the Node.js versions supported on version 4.x.
Add both
version
andextensionBundle
elements to the host.json, so that it looks like the following example:{ "version": "2.0", "extensionBundle": { "id": "Microsoft.Azure.Functions.ExtensionBundle", "version": "[3.3.0, 4.0.0)" } }
The
extensionBundle
element is required because after version 1.x, bindings are maintained as external packages. For more information, see Extension bundles.Update your local.settings.json file so that it has at least the following elements:
{ "IsEncrypted": false, "Values": { "AzureWebJobsStorage": "UseDevelopmentStorage=true", "FUNCTIONS_WORKER_RUNTIME": "node" } }
The
AzureWebJobsStorage
setting can be either the Azurite storage emulator or an actual Azure storage account. For more information, see Local storage emulator.
Update your function app in Azure
You need to update the runtime of the function app host in Azure to version 4.x before you publish your migrated project. The runtime version used by the Functions host is controlled by the FUNCTIONS_EXTENSION_VERSION
application setting, but in some cases other settings must also be updated. Both code changes and changes to application settings require your function app to restart.
The easiest way is to update without slots and then republish your app project. You can also minimize the downtime in your app and simplify rollback by updating using slots.
Update without slots
The simplest way to update to v4.x is to set the FUNCTIONS_EXTENSION_VERSION
application setting to ~4
on your function app in Azure. You must follow a different procedure on a site with slots.
az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~4 -g <RESOURCE_GROUP_NAME> -n <APP_NAME>
You must also set another setting, which differs between Windows and Linux.
When running on Windows, you also need to enable .NET 6.0, which is required by version 4.x of the runtime.
az functionapp config set --net-framework-version v6.0 -g <RESOURCE_GROUP_NAME> -n <APP_NAME>
.NET 6 is required for function apps in any language running on Windows.
In this example, replace <APP_NAME>
with the name of your function app and <RESOURCE_GROUP_NAME>
with the name of the resource group.
You can now republish your app project that has been migrated to run on version 4.x.
Update using slots
Using deployment slots is a good way to update your function app to the v4.x runtime from a previous version. By using a staging slot, you can run your app on the new runtime version in the staging slot and switch to production after verification. Slots also provide a way to minimize downtime during the update. If you need to minimize downtime, follow the steps in Minimum downtime update.
After you've verified your app in the updated slot, you can swap the app and new version settings into production. This swap requires setting WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0
in the production slot. How you add this setting affects the amount of downtime required for the update.
Standard update
If your slot-enabled function app can handle the downtime of a full restart, you can update the WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS
setting directly in the production slot. Because changing this setting directly in the production slot causes a restart that impacts availability, consider doing this change at a time of reduced traffic. You can then swap in the updated version from the staging slot.
The Update-AzFunctionAppSetting
PowerShell cmdlet doesn't currently support slots. You must use Azure CLI or the Azure portal.
Use the following command to set
WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0
in the production slot:az functionapp config appsettings set --settings WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 -g <RESOURCE_GROUP_NAME> -n <APP_NAME>
In this example, replace
<APP_NAME>
with the name of your function app and<RESOURCE_GROUP_NAME>
with the name of the resource group. This command causes the app running in the production slot to restart.Use the following command to also set
WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS
in the staging slot:az functionapp config appsettings set --settings WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 -g <RESOURCE_GROUP_NAME> -n <APP_NAME> --slot <SLOT_NAME>
Use the following command to change
FUNCTIONS_EXTENSION_VERSION
and update the staging slot to the new runtime version:az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~4 -g <RESOURCE_GROUP_NAME> -n <APP_NAME> --slot <SLOT_NAME>
Version 4.x of the Functions runtime requires .NET 6 in Windows. On Linux, .NET apps must also update to .NET 6. Use the following command so that the runtime can run on .NET 6:
When running on Windows, you also need to enable .NET 6.0, which is required by version 4.x of the runtime.
az functionapp config set --net-framework-version v6.0 -g <RESOURCE_GROUP_NAME> -n <APP_NAME>
.NET 6 is required for function apps in any language running on Windows.
In this example, replace
<APP_NAME>
with the name of your function app and<RESOURCE_GROUP_NAME>
with the name of the resource group.If your code project required any updates to run on version 4.x, deploy those updates to the staging slot now.
Confirm that your function app runs correctly in the updated staging environment before swapping.
Use the following command to swap the updated staging slot to production:
az functionapp deployment slot swap -g <RESOURCE_GROUP_NAME> -n <APP_NAME> --slot <SLOT_NAME> --target-slot production
Minimum downtime update
To minimize the downtime in your production app, you can swap the WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS
setting from the staging slot into production. After that, you can swap in the updated version from a prewarmed staging slot.
Use the following command to set
WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0
in the staging slot:az functionapp config appsettings set --settings WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 -g <RESOURCE_GROUP_NAME> -n <APP_NAME> --slot <SLOT_NAME>
Use the following commands to swap the slot with the new setting into production, and at the same time restore the version setting in the staging slot.
az functionapp deployment slot swap -g <RESOURCE_GROUP_NAME> -n <APP_NAME> --slot <SLOT_NAME> --target-slot production az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~3 -g <RESOURCE_GROUP_NAME> -n <APP_NAME> --slot <SLOT_NAME>
You may see errors from the staging slot during the time between the swap and the runtime version being restored on staging. This error can happen because having
WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0
only in staging during a swap removes theFUNCTIONS_EXTENSION_VERSION
setting in staging. Without the version setting, your slot is in a bad state. Updating the version in the staging slot right after the swap should put the slot back into a good state, and you call roll back your changes if needed. However, any rollback of the swap also requires you to directly removeWEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0
from production before the swap back to prevent the same errors in production seen in staging. This change in the production setting would then cause a restart.Use the following command to again set
WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0
in the staging slot:az functionapp config appsettings set --settings WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0 -g <RESOURCE_GROUP_NAME> -n <APP_NAME> --slot <SLOT_NAME>
At this point, both slots have
WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS=0
set.Use the following command to change
FUNCTIONS_EXTENSION_VERSION
and update the staging slot to the new runtime version:az functionapp config appsettings set --settings FUNCTIONS_EXTENSION_VERSION=~4 -g <RESOURCE_GROUP_NAME> -n <APP_NAME> --slot <SLOT_NAME>
Version 4.x of the Functions runtime requires .NET 6 in Windows. On Linux, .NET apps must also update to .NET 6. Use the following command so that the runtime can run on .NET 6:
When running on Windows, you also need to enable .NET 6.0, which is required by version 4.x of the runtime.
az functionapp config set --net-framework-version v6.0 -g <RESOURCE_GROUP_NAME> -n <APP_NAME>
.NET 6 is required for function apps in any language running on Windows.
In this example, replace
<APP_NAME>
with the name of your function app and<RESOURCE_GROUP_NAME>
with the name of the resource group.If your code project required any updates to run on version 4.x, deploy those updates to the staging slot now.
Confirm that your function app runs correctly in the updated staging environment before swapping.
Use the following command to swap the updated and prewarmed staging slot to production:
az functionapp deployment slot swap -g <RESOURCE_GROUP_NAME> -n <APP_NAME> --slot <SLOT_NAME> --target-slot production
Behavior changes after version 1.x
This section details changes made after version 1.x in both trigger and binding behaviors as well as in core Functions features and behaviors.
Changes in triggers and bindings
Starting with version 2.x, you must install the extensions for specific triggers and bindings used by the functions in your app. The only exception for this HTTP and timer triggers, which don't require an extension. For more information, see Register and install binding extensions.
There are also a few changes in the function.json or attributes of the function between versions. For example, the Event Hubs path
property is now eventHubName
. See the existing binding table for links to documentation for each binding.
Changes in features and functionality
A few features were removed, updated, or replaced after version 1.x. This section details the changes you see in later versions after having used version 1.x.
In version 2.x, the following changes were made:
Keys for calling HTTP endpoints are always stored encrypted in Azure Blob storage. In version 1.x, keys were stored in Azure Files by default. When you migrate an app from version 1.x to version 2.x, existing secrets that are in Azure Files are reset.
The version 2.x runtime doesn't include built-in support for webhook providers. This change was made to improve performance. You can still use HTTP triggers as endpoints for webhooks.
To improve monitoring, the WebJobs dashboard in the portal, which used the
AzureWebJobsDashboard
setting is replaced with Azure Application Insights, which uses theAPPINSIGHTS_INSTRUMENTATIONKEY
setting. For more information, see Monitor Azure Functions.All functions in a function app must share the same language. When you create a function app, you must choose a runtime stack for the app. The runtime stack is specified by the
FUNCTIONS_WORKER_RUNTIME
value in application settings. This requirement was added to improve footprint and startup time. When developing locally, you must also include this setting in the local.settings.json file.The default timeout for functions in an App Service plan is changed to 30 minutes. You can manually change the timeout back to unlimited by using the functionTimeout setting in host.json.
HTTP concurrency throttles are implemented by default for Consumption plan functions, with a default of 100 concurrent requests per instance. You can change this behavior in the
maxConcurrentRequests
setting in the host.json file.Because of .NET Core limitations, support for F# script (
.fsx
files) functions has been removed. Compiled F# functions (.fs) are still supported.The URL format of Event Grid trigger webhooks has been changed to follow this pattern:
https://{app}/runtime/webhooks/{triggerName}
.The names of some pre-defined custom metrics were changed after version 1.x.
Duration
was replaced withMaxDurationMs
,MinDurationMs
, andAvgDurationMs
.Success Rate
was also renamed toSuccess Rate
.
Considerations for Azure Stack Hub
App Service on Azure Stack Hub does not support version 4.x of Azure Functions. When you are planning a migration off of version 1.x in Azure Stack Hub, you can choose one of the following options:
- Migrate to version 4.x hosted in public cloud Azure Functions using the instructions in this article. Instead of upgrading your existing app, you would create a new app using version 4.x and then deploy your modified project to it.
- Switch to WebJobs hosted on an App Service plan in Azure Stack Hub.