.NET 8 Support Ends November 10: The Lambda and Azure Functions Checklist

On November 10, 2026, four deadlines land on one Patch Tuesday: .NET 8 and .NET 9 reach end of support, AWS deprecates the Lambda dotnet8 runtime, and Azure Functions drops the in-process model. Nothing stops running. Security patching stops, so start the move to .NET 10, supported until November 14, 2028, this week.

What actually changes on November 10

Microsoft's support policy page, updated October 25, gives .NET 8 and .NET 9 the same end date, November 10, 2026. The October patches, 8.0.33 and 9.0.22, are among the last. After that, a CVE in the runtime or ASP.NET Core stays open on those versions for good.

The cloud platforms follow the runtime. Here is the whole picture in one table, as of October 2026:

Teams misread the Lambda row. AWS says you can keep invoking deprecated functions "indefinitely", but AWS "may no longer apply security patches", support ends, and console editing stops. CLI, SAM and CloudFormation deploys work until the block dates. The deadline that matters is when nobody patches the runtime under your code: November 10.

Step 1: find every affected function and app

AWS's emails and Health Dashboard list only $LATEST versions, and only reach accounts whose contact email is read. Run the inventory yourself, per account:

# Lambda: every version on dotnet8, every region
$ for r in $(aws ec2 describe-regions --query 'Regions[].RegionName' --output text); do
    aws lambda list-functions --function-version ALL --region "$r" --output text \
      --query "Functions[?Runtime=='dotnet8'].FunctionArn"
  done

# Azure Functions: apps still on the in-process model
$ az functionapp list --query "[].[name, resourceGroup]" -o tsv |
  while read -r name rg; do
    rt=$(az functionapp config appsettings list -n "$name" -g "$rg" \
      --query "[?name=='FUNCTIONS_WORKER_RUNTIME'].value | [0]" -o tsv)
    [ "$rt" = "dotnet" ] && echo "in-process: $rg/$name"
  done

Two blind spots. Container image functions have no Runtime field, so dotnet9 (container only on Lambda) and any image built FROM a .NET 8 base never show up in that query; grep your Dockerfiles for the base image tag instead. On Azure, FUNCTIONS_WORKER_RUNTIME=dotnet means in-process; dotnet-isolated means you are already on the right model, but the app can still be pinned to .NET 8 in its stack configuration and needs the same framework bump.

Step 2: Lambda, rebuild on net10.0 and ship code and runtime together

A Lambda runtime change for .NET is not a config flip. A framework-dependent assembly built for net8.0 will not roll forward to a different major version by default, so changing the runtime identifier without recompiling breaks the function. Set <TargetFramework>net10.0</TargetFramework>, bump Amazon.Lambda.* packages, rebuild, and deploy code and Runtime: dotnet10 in the same SAM, CDK or Terraform change.

Roll it out behind a version and an alias, as AWS recommends, so the previous version stays one alias update away. That rollback works only until August 31, 2027; after the update block, AWS warns, "rolling back to the deprecated runtime may be blocked." If you are also moving to arm64, the native-dependency traps are the ones in what broke in our Graviton migration; do one change at a time.

Step 3: Azure Functions, in-process to isolated worker

This is the bigger job: the programming model changes, not only the framework. Microsoft's guide targets .NET 10 (or .NET Framework 4.8 for Framework-only APIs). In the order the build errors force on you:

1. Project file. Set Sdk="Azure.Functions.Sdk/1.0.0", TargetFramework to net10.0, and replace Microsoft.NET.Sdk.Functions with Microsoft.Azure.Functions.Worker (2.52.0 in the guide) plus the ASP.NET Core HTTP extension and the Application Insights worker packages.
2. Package swaps. Every Microsoft.Azure.WebJobs.Extensions.* package gets its Microsoft.Azure.Functions.Worker.Extensions.* counterpart (Service Bus, Cosmos DB, Event Hubs, Durable Task, and so on). Remove Microsoft.Azure.Functions.Extensions entirely. The guide is explicit: no Microsoft.Azure.WebJobs.* references may remain.
3. Program.cs replaces Startup.cs. Anything you registered in FunctionsStartup moves into ConfigureServices.
4. Signatures. [FunctionName] becomes [Function], the ILogger method parameter becomes a constructor-injected ILogger<T>, input bindings gain an Input suffix and output bindings an Output suffix and move to the return type.
5. Settings. FUNCTIONS_WORKER_RUNTIME becomes dotnet-isolated, locally and in Azure.

The new entry point, straight from the guide. Swap ConfigureFunctionsWebApplication() for ConfigureFunctionsWorkerDefaults() if the app has no HTTP triggers:

// Program.cs
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();

Roll out through a staging slot: set FUNCTIONS_WORKER_RUNTIME=dotnet-isolated there (not as a slot setting), publish the migrated build, test, then swap. Making both changes on production leaves a window where code and runtime disagree.

The failure modes you will actually hit

• AZFD0013, the runtime/payload mismatch. You changed FUNCTIONS_WORKER_RUNTIME but the old in-process build is still deployed, or the reverse. It clears once both changes land, which is exactly why the slot swap exists.
• InvalidOperationException: Synchronous operations are disallowed. ASP.NET Core integration forbids sync stream I/O. Replace ReadToEnd with ReadToEndAsync, Write with WriteAsync, and make the function async Task<IActionResult>.
• Silent JSON nulls. The isolated model defaults to System.Text.Json, which ignores Newtonsoft's [JsonProperty] and [JsonIgnore] and binds affected properties to defaults "without reporting an error." Grep for those attributes before you ship, or this one reaches production quietly.

Step 4: a CI gate so net8.0 does not come back

Inventory is a snapshot; a gate keeps it true. This fails any pull request still targeting .NET 8 or 9, including multi-target TargetFrameworks and Directory.Build.props. It fits the patterns in our GitHub Actions recipes:

# .github/workflows/tfm-gate.yml
name: tfm-gate
on: [pull_request]
jobs:
  no-eol-dotnet:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Fail on net8.0 / net9.0 targets
        run: |
          if grep -rnE --include='*.csproj' --include='*.props' \
               '<TargetFrameworks?>[^<]*net(8|9)\.0' .; then
            echo "::error::End-of-support .NET target found (support ended 2026-11-10)"
            exit 1
          fi

Extend the pattern to Runtime: dotnet8 in your IaC to cover deployment config too.

Where this breaks

The gate only sees repositories it runs in; hand-deployed functions still need the CLI inventory. Durable Functions migrations carry their own storage-provider swaps and need a separate test pass. And .NET Framework 4.8 isolated apps follow Windows and Framework support rules, not the dates in this post.

Questions people ask

Will my Lambda function stop working on November 10, 2026?

No. AWS says you can keep invoking functions on a deprecated runtime indefinitely. From November 10 the dotnet8 runtime stops getting security patches, loses technical support and can no longer be edited in the console. Creating new dotnet8 functions is blocked from July 29, 2027 and updating existing ones from August 31, 2027, so plan the move well before then.

Can I keep the Azure Functions in-process model on .NET 8 after November 10?

The app keeps running, but Microsoft ends support for the in-process model on November 10, 2026, the same day .NET 8 support ends. You stop getting platform support and runtime patches. Microsoft's guidance is to migrate to the isolated worker model and target .NET 10, using a staging slot so the runtime setting and the deployed code change together.

Should I move to .NET 9 instead of .NET 10?

No. .NET 9 is a Standard Term Support release and ends support on the same day as .NET 8. Moving to it buys nothing. .NET 10 is the current LTS, supported until November 14, 2028, and it is the target for both the Lambda dotnet10 runtime and Microsoft's in-process migration guide.

The call we'd make

Run both inventory commands today, put the CI gate in every .NET repository this week, and migrate Azure in-process apps first, because they need code changes, not a rebuild. Lambda dotnet8 functions are a recompile and redeploy, so batch them behind aliases right after. The caveat: if a function is invoked rarely and touches nothing sensitive, it can wait for the next sprint, but put a date on it before the 2027 blocks decide for you.

Sources

• .NET and .NET Core official support policy
• AWS Lambda runtimes and deprecation schedule
• Migrate C# apps from the in-process model to the isolated worker model
• az functionapp config appsettings reference