.NET 8 End of Support on November 10: What Actually Needs Attention

On November 10, 2026, Microsoft stops shipping security fixes for .NET 8. Most organizations know that date is coming. Far fewer know exactly which of their applications are affected, and that gap is where the risk sits.

The .NET 8 end of support date also catches a second version. Microsoft extended Standard Term Support releases from 18 to 24 months, which moved .NET 9's end date to the same day. Teams that skipped ahead to .NET 9 to stay current are on the same clock as everyone still on 8.

What Changes on November 10

Nothing breaks that morning. Microsoft is explicit that applications built on .NET 8 or .NET 9 will continue to run after the date. What stops is the flow of servicing updates, security patches, and technical support.

That distinction matters for how you plan. An unsupported runtime is not an outage. It is an exposure that grows every month, because every vulnerability disclosed after November 10 stays open in your environment for as long as the application stays on 8 or 9.

Here is where each version stands:

Dates from Microsoft's .NET support policy.

The support gap also shows up outside engineering. Security questionnaires, cyber insurance renewals, and audit evidence increasingly ask whether production systems run supported software. "Yes, except these four apps" is a harder answer to give after November 10.

Start With an Inventory, Not an Upgrade

The most common mistake we see is treating this as a single project. In most mid-market and enterprise environments, .NET 8 is spread across a dozen places nobody has listed together. Before anyone retargets a project file, build the list.

Look in these places:

• Customer-facing applications. Portals, ordering tools, account dashboards, and APIs that partners call.
• Internal line-of-business apps. Approval workflows, quoting tools, reporting dashboards, and admin consoles that were built once and rarely touched since.
• Integration services. The middleware that moves data between your ERP, CRM, and warehouse systems. These are easy to forget because they have no user interface.
• Background workers and scheduled jobs. Windows services, Azure Functions, and console apps that run overnight imports or reconciliations.
• Vendor-supplied software. Commercial products built on .NET 8 that your team does not maintain directly.

For each one, capture the target framework, who owns it, where it is hosted, and what it touches. The last column matters most. An internal report generator that reads one database is a very different risk from an API that handles payment data.

Vendor software needs a different approach. You cannot upgrade it yourself, so Microsoft's advice is to contact the vendor and ask for a version built on .NET 10. Get that answer in writing now, because some vendors will not have one ready by November.

What Upgrading to .NET 10 Actually Involves

For a well-maintained application, the core change is small. You change the TargetFramework property in the project file to net10.0 and update your development and hosting environments, as covered in Microsoft's upgrade guide.

The real work usually lives elsewhere.

Breaking changes

Every major release ships a list of behavior changes. Microsoft publishes the full set in its .NET 10 breaking changes reference. Most will not affect a given app, but someone needs to read the list against your codebase rather than discovering the relevant ones in production.

Third-party packages

This is where timelines slip. An application might depend on 40 NuGet packages, and each one needs a version that supports .NET 10. Abandoned packages are the hard case. If a library has not been updated in two years, the upgrade may turn into a replacement.

Hosting and pipelines

Servers, containers, and App Service plans need the .NET 10 runtime. Build agents need the new SDK. If your team has CI/CD pipelines for ASP.NET Core in place, this is a configuration change. If deployments are still manual, the upgrade is a good moment to fix that, since you will be deploying every one of these apps at least once.

Testing

The upgrade is only as safe as your ability to prove nothing changed. Applications with automated tests can move quickly. Applications without them need a manual regression plan, and that is usually what determines how long the project takes.

How to Prioritize With Three Weeks Left

Few organizations will finish every upgrade by November 10. That is fine, as long as the order is deliberate. We rank applications on two factors: exposure and effort.

High-exposure applications that will not make the date need compensating controls in the meantime. That can mean tightening network access, putting a web application firewall in front of them, and increasing monitoring. None of these replace a supported runtime, but they reduce the window an attacker has to work with.

Low-exposure internal tools can follow in a planned sequence. Write down which apps are knowingly past support and when each will move. A documented, dated plan is something you can show an auditor. An undocumented gap is not.

Where .NET Framework Fits

Older applications on .NET Framework 4.x are not part of this deadline. .NET Framework follows a separate lifecycle tied to the Windows version it runs on, so a Framework app is not suddenly unsupported on November 10.

That does not make it a safe place to stay. Framework apps tend to be the oldest, least documented systems in an estate, and they cannot use anything built for modern .NET. If you are already touching the portfolio for this deadline, it is worth flagging which Framework apps belong on a modernization path that avoids a full rewrite.

Treat the Deadline as a Debt Review

An upgrade like this exposes things. Packages nobody owns. Apps with no tests. Integrations that only one person understands. Those are the same issues that make every future change slow and expensive, which is what technical debt actually costs a business.

The teams that come out of this well use the inventory twice. Once to hit the date, and again to decide which applications deserve investment and which should be retired. .NET 10 is supported through November 2028, so the next deadline of this kind is already on the calendar.

Getting Help With the Upgrade

We have been building and maintaining enterprise .NET applications for years, and version upgrades are routine work for our team. Our ASP.NET Core migration and upgrade services cover the inventory, the dependency review, the upgrade itself, and the regression testing that proves it worked.

If you are not sure what in your environment runs on .NET 8, start there. We can help you build the list, rank it, and get the highest-risk applications moved first. Contact our team to talk through your portfolio.