.NET 8 Support Ends November 10. LTS Meant Three Years

Next Tuesday, November 10, Microsoft stops supporting .NET 8 (Microsoft). .NET 8 is a Long Term Support release. It shipped on November 14, 2023. Long term, it turns out, was three years.

.NET 9 goes out of support the same day. .NET 9 is a Standard Term Support release, and when it shipped it was due to end in May 2026. In September 2025, Microsoft lengthened STS from 18 months to 24, starting with .NET 9. "This means that .NET 8 and .NET 9 will reach end of support on the same day," the announcement said (.NET Blog).

That is a lot of software. JetBrains' State of .NET 2025 report, drawing on more than 3,800 professionals, found 56% regularly used .NET 8 and 44% used .NET 9, with respondents able to pick more than one (JetBrains).

Skipping the odd-numbered release and waiting for the next LTS saved nothing this time. Teams that stayed on 8 and teams that moved to 9 have the same deadline, and a week left. The only supported landing is .NET 10, an LTS release supported until November 14, 2028.

What "out of support" actually means

Nothing switches off on November 10. Microsoft's own end-of-support post says .NET 8 and 9 apps keep running, but "no new security updates will be issued" and technical support ends (.NET Blog). Azure App Service says the same: apps "continue to run unchanged," but App Service "can't provide security patches or related customer support for that runtime version" (Microsoft Learn). AWS Lambda deprecates its dotnet8 runtime on the same day, may stop patching it, and blocks creating new .NET 8 functions from July 29, 2027 (AWS).

That is why the date is easy to miss. There is no outage to force the issue. The cost arrives later, with the first .NET vulnerability that gets fixed in .NET 10 and not in .NET 8. .NET patches ship on Patch Tuesday, the second Tuesday of the month. The first one after the cutoff is December 8, and any fix released from then on will not come to .NET 8.

Three details make this sharper than it looks.

.NET 8 has been security-only since spring. Microsoft's policy puts every release into a maintenance phase for its final six months, when it is updated "to mitigate security vulnerabilities, only." The long-term part of long-term support ended around May.

Supported means the latest patch. The same policy says customers "need the latest patch update installed to qualify for support." An app on .NET 10 that is behind on patches does not qualify for support either.

The warnings may not have reached the right people. App Service sends end-of-support reminders to subscription owners and administrators. Contributors and readers, which can include the engineers who actually own the app, don't get them unless they opt in to Service Health alerts.

Why this is not just a version bump

Microsoft's recommended path starts with changing TargetFramework to net10.0 and updating development and hosting environments. That is the starting point. The trouble is what is attached to it.

Azure Functions on the in-process model. Support for the in-process model also ends on November 10, and Microsoft's version table lists .NET 8 as the only version it runs on (Microsoft Learn). .NET 10 appears only under the isolated worker model. Moving means migrating to the isolated worker model: a changed project file and package references, a new Program.cs, changes to function signatures and bindings, and a coordinated switch of the worker runtime setting when you deploy (Microsoft Learn). For apps on retired language versions, Azure Functions' policy also says that "in certain cases" it will limit instances, "including limit scaling to 1 instance" (Microsoft Learn).

Entity Framework Core. EF Core 8 and EF Core 9 both run on .NET 8, and both lose support on November 10. EF Core 10 targets .NET 10 (Microsoft Learn). The data layer moves with the runtime.

Scripts and automation. PowerShell 7.4, built on .NET 8, and PowerShell 7.5, built on .NET 9, also reach end of support on November 10. The current LTS is PowerShell 7.6 (Microsoft Learn). Deployment pipelines and ops scripts count.

Consider a hypothetical mid-market distributor. Its customer portal is ASP.NET Core on .NET 8 in App Service. A dozen Azure Functions on the in-process model handle order events. Data access is EF Core 8 against SQL Server, and the release pipeline runs PowerShell 7.4.

The portal is the easy part: retarget, update packages, run the tests, deploy through staging. The functions are a model migration, one function at a time. EF Core moves with the runtime, so data access code is in scope and needs its own regression pass. And the pipeline that deploys all of it runs on a PowerShell version that loses support the same day. If nobody has started, little of that will be finished by next Tuesday. All of it can be inventoried and ranked by then.

What to do this week

1. Inventory every .NET 8 and .NET 9 workload. Web apps, Azure Functions, background services, container images, Lambda functions, internal tools. Record the hosting model and a named owner for each.
2. Rank by exposure. Internet-facing services and anything handling sensitive data go first. Internal batch jobs can follow.
3. Find the in-process functions. Microsoft's migration guide has you switch FUNCTIONS_WORKER_RUNTIME to dotnet-isolated as part of the move, so a function app still set to dotnet is the place to look. Those apps need a migration plan, not a retarget.
4. Move the simple apps now. Retarget to net10.0, update Microsoft packages including EF Core, update the SDK on build agents, run the tests, and deploy through a staging slot.
5. Stay on the latest patch. Once on .NET 10, apply each monthly patch. Support depends on it.
6. Write down what can't move by the 10th. Owner, target date, and what limits the exposure in the meantime. A risk accepted in writing is better than one nobody knows about.
7. Fix who gets the notices. Opt the owning engineers in to Azure Service Health alerts so the next deadline reaches them directly.

The real lesson is the calendar

Microsoft ships a new major .NET version every November. Even-numbered releases are LTS, supported for three years. Odd-numbered releases are STS, now supported for two (Microsoft). A team that only takes LTS releases gets a new one every two years, and one year of overlap to move before the old one expires.

.NET 11 is due to launch at .NET Conf, November 10 to 12 (.NET Blog), the same week .NET 8 goes out of support. .NET 10 has its own deadline, November 14, 2028.

That date will arrive the same way this one did, unless the upgrade becomes routine work: a line in every annual budget, a test suite that makes retargeting uneventful, and a named owner for runtime versions, the way someone already owns certificate renewals. Treated as a once-every-three-years project, it will always land as a deadline.

If you have .NET 8 or 9 workloads and no plan yet, we can help you sort out what moves first. Talk to us at midrasolutions.com.