End of support on November 10, 2026: .NET 8, .NET 9 and Azure Functions in-process — what to do now

On November 10, 2026, nothing will happen at many companies. No outage, no alert, no error message. The applications simply keep running — and that is exactly the problem. On that day, support ends for .NET 8, for .NET 9 and for the Azure Functions in-process model. From then on, there are no more security updates for them.

This article sums up what exactly ends, why it matters even more for energy companies with public customer portals, and what an upgrade looks like that doesn't hurt in production. As of October 2026.

Key points

• November 10, 2026: end of support for .NET 8 (LTS), .NET 9 (STS) and Azure Functions in the in-process model.
• The apps keep running, but they get no more security updates, and Microsoft and Azure no longer provide support for these versions.
• The target is .NET 10 (LTS, supported until November 14, 2028).
• Azure Functions in the in-process model can't simply move to .NET 10 — they have to move to the isolated worker model.
• The upgrade is more than a version number: code and NuGet packages, Functions, pipelines and infrastructure have to fit together.

What exactly ends

.NET 8 is an LTS release with three years of support. .NET 9 would actually have ended in May 2026, but Microsoft extended support for STS releases from 18 to 24 months. That's why both end on the same day.

The third item is the one most often overlooked: Azure Functions in the in-process model only run on .NET 8. There is no path to a newer version there. If your functions need to move to .NET 10, you have to switch the model.

What about .NET 11? It ships in November 2026 and, thanks to the new STS rule, is also supported until 2028. For an upgrade under time pressure, .NET 10 is still the better choice: it has been in use for almost a year and is well proven.

What "end of support" really means

End of support doesn't mean shutdown. Microsoft states that applications on .NET 8 and 9 keep running; Azure App Service and Azure Functions keep hosting them.

What's missing are updates. .NET usually gets new versions every month on Patch Tuesday, often with security fixes. For .NET 8 and 9, that stops after November 10. The next critical vulnerability that becomes known stays open in the application.

Support is the other part: for Azure App Service, an app on an unsupported runtime has to be moved to a supported version before it gets support.

Why it hits energy companies hard

1. Customer portals are public. They process personal data: addresses, meter readings, bank details. An open vulnerability is not a theoretical risk there.
2. Regulation. Germany's NIS2 implementation act has been in force since December 6, 2025, and energy is a sector of high criticality. Section 30 of the BSIG explicitly requires security measures in the acquisition, development and maintenance of IT systems, including vulnerability management and disclosure. In an audit, the question is obvious: why does our customer portal run software without security updates?
3. Time. Change processes, approvals, test windows: in regulated environments an upgrade often takes weeks, not days.

More than a version number

On paper, a .NET upgrade is one line in the project:

<!-- before -->
<TargetFramework>net8.0</TargetFramework>
<!-- after -->
<TargetFramework>net10.0</TargetFramework>

In practice, it touches four layers.

1. Code and NuGet dependencies

Every library has to come along. Some packages no longer exist, some bring breaking changes. That includes the Dynamics 365 SDK if the application talks to the CRM. dotnet list package --outdated and --deprecated show early where the real work is.

2. Azure Functions: from in-process to the isolated worker model

The switch is a real rebuild:

• new packages (Microsoft.Azure.Functions.Worker.* instead of Microsoft.Azure.WebJobs.*)
• a new Program.cs instead of FunctionsStartup
• [Function] instead of [FunctionName], and input and output bindings are named differently
• logging via dependency injection (ILogger<T>) instead of an ILogger parameter
• FUNCTIONS_WORKER_RUNTIME = dotnet-isolated

public class Zaehler
{
    // In-process (Newtonsoft.Json): filled from "zaehler_nr".
    // Isolated (System.Text.Json): the attribute is ignored → Zaehlernummer stays null.
    [JsonProperty("zaehler_nr")]
    public string Zaehlernummer { get; set; }
}

The fix: switch the attributes to [JsonPropertyName("zaehler_nr")] or deliberately configure Newtonsoft.Json for these payloads — and write tests that check exactly these fields.

3. Pipelines

If the Azure DevOps pipeline still installs the .NET 8 SDK, the build fails with NETSDK1045:

- task: UseDotNet@2
  inputs:
    version: '10.x'   # was '8.x'

And without automated tests, breaking changes only show up in production.

4. Infrastructure as code

If Terraform still has the old runtime setting, the next deployment resets it. Then configuration and code no longer match, and the functions don't run (error AZFD0013). Runtime version and worker model therefore belong in the same change as the code:

app_settings = {
  FUNCTIONS_WORKER_RUNTIME = "dotnet-isolated"
}

The plan in five steps

1. Inventory. Which applications run on .NET 8 or 9? Which function apps still use the in-process model? For Azure Functions, Microsoft provides a PowerShell script that lists these apps — at its core:

   Get-AzFunctionApp | Where-Object Runtime -eq 'dotnet'

2. Prioritize. Whatever is public and processes customer data comes first. Internal batch jobs after that.

3. Upgrade in a separate branch, with automated tests. The upgrade agent in GitHub Copilot can take over part of the legwork; decisions and tests stay with the team.

4. Deploy through a staging slot. Test there first, then swap. Production never sees an intermediate state, and a rollback is a second swap.

5. Monitor. Application Insights and Azure Monitor show in the first days whether error rates or response times change.

If you can't make it by November 10

Nothing breaks on November 11. But make a conscious decision:

• Document the risk.
• Reduce the attack surface, for example by making internal APIs reachable only through private endpoints.
• Set a fixed date for the upgrade.

A documented plan with a date beats a silent "it still runs".

The next date: January 12, 2027

On January 12, 2027, support ends for Windows Server 2016. That affects you if .NET applications still run on your own servers with IIS — a good reason to plan the migration to Azure App Service at the same time.

From practice

In my last project, at an energy company, I upgraded an application from .NET 5 to .NET 8. The real work wasn't the version number but replacing deprecated dependencies and cleanly resolving their breaking changes. There I also wrote the complete infrastructure in Terraform and all pipelines in Azure DevOps, and migrated applications from IIS to Azure App Service. Details in the project pages below.

Sources

• .NET Blog: .NET 8 and .NET 9 will reach End of Support on November 10, 2026
• .NET Support Policy
• .NET STS releases supported for 24 months
• Azure Functions: Migrate C# apps from the in-process model to the isolated worker model
• Azure App Service: Language runtime support policy
• BSI: NIS2 implementation act in force (German)
• Section 30 BSIG (German)
• Windows Server 2016 end of support