TL;DR. .NET 8 end of support is November 10, 2026, and .NET 9 ends the same day. For most internal apps already on .NET 8, the fix is a retarget to .NET 10, which Microsoft supports until November 2028. The bigger exposure sits in your .NET Framework 4.x apps, whose support is tied to the Windows Server they run on, and Windows Server 2016 leaves extended support on January 12, 2027. Use this week to sort every .NET app you run into three buckets and give each one an owner and a date.

Tuesday, November 10, 2026 is Patch Tuesday. It is also the last day Microsoft ships fixes for .NET 8 and .NET 9. After that, your apps keep running exactly as they did on Monday. They just stop getting security patches, and nobody at Microsoft will take the support call.

That sounds like a .NET 8 problem. For most mid-market companies, .NET 8 end of support is really an inventory problem. A typical mid-market portfolio has a couple of newer .NET 8 services, a few ASP.NET MVC or Web Forms apps on .NET Framework 4.x, and at least one thing on .NET Core 3.1 or .NET 6 that somebody stood up in 2020 and nobody has touched since. Each of those has a different clock, and only one of them hits zero next week.

What .NET 8 end of support actually changes

Microsoft’s .NET support policy defines end of support plainly: Microsoft no longer provides fixes, updates, or online technical assistance. .NET 8 was a long term support (LTS) release, which gets three years. .NET 9 was a standard term support (STS) release, and since STS support now runs 24 months instead of 18, both versions end on the same date.

As of November 2026, here is what .NET 8 end of support changes on November 11:

• No more monthly servicing releases. The next vulnerability in ASP.NET Core or the runtime gets patched in .NET 10 and not in .NET 8.
• Azure App Service has posted its own retirement notice: security updates and customer support for .NET 8 on App Service end on the same date.
• Visual Studio 2022 will mark the .NET 8 and .NET 9 components as out of support in a future servicing update.
• Modern .NET has no paid extended security update program. When the patch stream ends, it ends.

What does not change: nothing breaks on November 11. That is exactly why .NET 8 end of support gets ignored. The risk builds quietly, and it usually surfaces in a cyber insurance questionnaire, an audit finding, or a customer security review that asks which of your systems run unsupported software.

Sort your .NET estate into three buckets

Before anyone opens a project file, make a list. Every internal app, service, scheduled job and API that runs on any flavor of .NET goes in one of three buckets. The bucket decides the effort, and the effort decides whether this is a sprint or a budget conversation.

Bucket	What is in it	Support clock	Typical effort
1. Modern and current	.NET 8 and .NET 9 apps	Ends November 10, 2026	Retarget to .NET 10. Days to a few weeks per app.
2. Framework on Windows	.NET Framework 4.6.2 to 4.8.1 apps	Follows the host Windows version. Windows Server 2016 and .NET Framework 4.6.2 end January 12, 2027.	Move the host now. Plan a port to .NET 10 on your own schedule.
3. Already expired	.NET Core 3.1, .NET 5, 6 and 7; .NET Framework 4.6.1 and older	Ended between 2022 and 2024	Real project. Often a rebuild of part of the app.

The table is deliberately blunt. Bucket 1 is the one getting the .NET 8 end of support headlines. Bucket 2 carries most of the business logic at a typical mid-market company. Bucket 3 is the one an auditor will find first.

Bucket 1: how to upgrade .NET 8 to .NET 10 without drama

For a well-kept ASP.NET Core app, the mechanical response to .NET 8 end of support is small. You set the TargetFramework in the project file to net10.0, update the SDK on build agents and developer machines, and update the runtime or container base image where the app is hosted. Microsoft’s own guidance describes the upgrade that way.

The work hides in three places. NuGet packages that pin an older Microsoft.Extensions or Entity Framework Core version. Breaking changes across two major versions, since going from 8 to 10 means you inherit everything that changed in 9 as well. And hosting: the App Service stack setting, the Docker base image, the build pipeline’s SDK task, and any deployment script that hardcodes a version.

Microsoft’s GitHub Copilot app modernization agent supports upgrades from .NET 5 and later to current versions. It writes an assessment listing breaking changes and API problems, then commits each step separately so you can review or roll back. It is a reasonable starting point. It is not a substitute for a test suite.

That last point is the real gating factor. If an app has decent automated tests, the move to .NET 10 is mostly a build and verify exercise. If it has none, you are about to ship a runtime change into production with nothing but manual clicking to catch regressions. In that case, write the smoke tests first. The tests outlive the upgrade.

Bucket 2: .NET Framework 4.8 support runs on a clock you do not see

Here is the part most teams miss. .NET Framework 4.5.2 and later is a component of Windows. Per Microsoft’s lifecycle FAQ, it follows the lifecycle policy of the Windows version it is installed on. .NET Framework 4.8 support has no end date of its own. It ends when the host operating system does.

So the question for a Framework app has nothing to do with .NET 8 end of support. The question is which Windows Server it runs on. If the answer is Windows Server 2016, the date that matters is January 12, 2027, when Windows Server 2016 end of support arrives. .NET Framework 4.6.2 ends on that same day. That is nine weeks after .NET 8 end of support.

Moving a Framework app to Windows Server 2022 or 2025 keeps .NET Framework 4.8 supported and buys real time. That is a legitimate decision, and for some apps it is the right one. But be clear about what you are buying. .NET Framework gets security fixes and no new features. The libraries you depend on are steadily dropping it. And the people who know Web Forms and WCF well are getting harder and more expensive to hire, which we covered in the real math on legacy stack hiring.

A host move is a holding action. Put a date on the port when you make it, or the holding action becomes the plan.

Bucket 3: the apps that already missed their deadline

.NET 6 left support on November 12, 2024. .NET Core 3.1 left on December 13, 2022. If an app in your portfolio still runs on either one, it has been unpatched for years, and the .NET 8 end of support news is your reminder, not your deadline.

These apps rarely upgrade cleanly. A .NET Core 3.1 app jumping to .NET 10 crosses six major versions of breaking changes, a different hosting model, and package versions that may no longer exist. In practice we treat Bucket 3 like a small modernization project: read the code, write down what the app does, decide what to keep, and rebuild against that written spec rather than patching forward version by version.

When a version bump becomes legacy .NET application modernization

Not every Framework app needs a rewrite, and not every .NET 8 app is safe to retarget. These signals tell you a version bump is the wrong tool and legacy .NET application modernization is the honest name for the work:

• The UI depends on Web Forms, WCF services, or front-end libraries a decade old, like jQuery 1.x or Knockout 2.x.
• One engineer understands the app, and nobody else can deploy it.
• Servers and cloud resources were built by hand, so nobody can recreate the environment from scratch.
• Every content or configuration change still needs a developer.
• It depends on a vendor component that stopped shipping releases years ago.

Two or more of those and you are past a framework upgrade. The useful move is to scope the app properly now, while the .NET 8 end of support deadline has leadership’s attention, instead of waiting for the next audit to force it.

What a .NET Framework 4.7 to .NET 10 move looked like for us

Bucket 2 and 3 apps take more than a retarget. We recently finished exactly this kind of move. The ACLSOnline V2 rebuild took an ASP.NET MVC 4 application on .NET Framework 4.7, with a proprietary CMS that had not shipped a release since around 2017, and moved it to .NET 10 LTS with Umbraco 17. First commit to production launch took five months, from May 14 to October 14, 2026.

Three things from that project apply to any Bucket 2 or Bucket 3 app. First, discovery spikes paid for themselves. We ran more than a dozen before writing production code, including NHibernate 5 on .NET 10 and an inventory of 396 Razor views and 531 URLs. The Razor view count turned out to be the plan’s biggest underestimate, and we caught it before it could blow up the schedule.

Second, target versions are a security decision. The plan originally called for Umbraco 15. Unpatched CVEs in 15.x moved us to Umbraco 17 on .NET 10 LTS. Third, the spec carried the project. We used Spec-Driven Development with Claude Code as the AI coding agent, and the written plans, architecture decision records and 70+ dated findings were the source of truth. The app shipped with more than 4,480 automated tests and runs on smaller Azure tiers than the version it replaced.

If you want to see what that kind of written plan looks like before you commit to anything, our sample modernization spec is public.

A one-week triage plan for your .NET apps

You do not need a consultant to start. You need a spreadsheet and a few honest conversations. This is the order we would work in:

1. List every .NET app, service and scheduled job, with its owner, its target framework, and the Windows or Linux host it runs on.
2. Tag each one Bucket 1, 2 or 3 using the table above.
3. For Bucket 1, check test coverage and schedule the .NET 10 retarget, starting with anything internet-facing.
4. For Bucket 2, find every Windows Server 2016 host and decide: move the host before January 12, 2027, or start the port.
5. For Bucket 3, write one page per app on what it does and who depends on it. That page is the start of a spec.
6. Give the list to whoever answers your cyber insurance questionnaire. After .NET 8 end of support, they will be asked about it.

Most teams can do this in a week. The list itself is the valuable artifact. It turns .NET 8 end of support from a headline into a plan with dates on it.

Frequently asked questions

If your list has more Bucket 2 and Bucket 3 apps than you expected, that is normal. Book a modernization discovery call and we will help you sort what to retarget, what to rehost, and what to rebuild.