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

URL: https://www.devopsness.com/blog/dotnet-8-end-of-support-november-10-lambda-azure-functions
Author: Kiril Urbonas
Published: 2026-10-31
Updated: 2026-10-31
Categories: Cloud
Tags: Serverless, AWS, Azure, Migration, Security, CI/CD

Summary: .NET 8, .NET 9, the Lambda dotnet8 runtime and the Azure Functions in-process model all lose support on November 10, 2026. Inventory commands, the isolated-worker migration and a CI gate.

---
# .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.

> [!VERIFIED]
> .NET 8.0.33, .NET 9.0.22 and .NET 10.0.14, against the dotnet.microsoft.com support policy, the AWS Lambda runtimes page, the Azure Functions in-process to isolated migration guide and the `az functionapp config appsettings` reference. Checked October 2026.

## 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:

| Workload | Support ends | What stops | Hard block | Move to |
|---|---|---|---|---|
| .NET 8 / .NET 9 runtime | Nov 10, 2026 | Security patches | None, it just ages | .NET 10 (to Nov 14, 2028) |
| Lambda `dotnet8` (zip) | Nov 10, 2026 | Patches, support, console edits | Create Jul 29, 2027; update Aug 31, 2027 | `dotnet10` |
| Lambda `dotnet9` (container only) | Nov 10, 2026 | Base image patches | Not scheduled | `dotnet10` base image |
| Azure Functions in-process | Nov 10, 2026 | Platform support | Not published | Isolated worker on .NET 10 |

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:

```bash
# 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](/blog/aws-graviton-migration-what-broke-what-we-saved); 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:

```csharp
// 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](/blog/github-actions-recipes):

```yaml
# .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](https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core)
- [AWS Lambda runtimes and deprecation schedule](https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html)
- [Migrate C# apps from the in-process model to the isolated worker model](https://learn.microsoft.com/en-us/azure/azure-functions/migrate-dotnet-to-isolated-model)
- [az functionapp config appsettings reference](https://learn.microsoft.com/en-us/cli/azure/functionapp/config/appsettings)