On November 10, 2026, Microsoft stops shipping security and reliability fixes for .NET 8 and .NET 9. Applications on either version keep running after that date, but newly found platform vulnerabilities no longer get a Microsoft patch. The recommended target is .NET 10, the current Long Term Support release, which is supported until November 14, 2028. Until a system moves, it should run the latest monthly patch for its current version, because those fixes keep coming until the end date.
Which .NET a System Actually Runs
The name .NET covers two products, and the November date applies to only one of them. It applies to modern .NET, the cross-platform line released each November as .NET 8, 9 and 10. The target framework in each project file settles it: net8.0 or net9.0, including desktop forms such as net8.0-windows, means the date applies. net48, net472 and similar values are .NET Framework.
.NET Framework is Windows-only and follows a different policy. Microsoft's .NET Framework lifecycle page treats it as a component of the Windows version it is installed on, so 4.7 through 4.8.1 carry no separate end date there. A few older versions do have their own dates on that page, including January 12, 2027 for 4.6.2. Support also depends on the underlying Windows version.
For each system in scope, record the target framework, where it is hosted, how it is deployed, and who approves its upgrade. Internal tools, scheduled jobs and worker services can also be missing from that list.
Packages and Vendor Software That Can Block the Move
Changing the target to net10.0 is the first edit, and the rebuild and test run show what else has to change. A NuGet package does not need a release labeled for .NET 10 to work: one built for an older target or for .NET Standard may run unchanged. The package that blocks an upgrade is one that is abandoned or incompatible, and it can arrive transitively through another package, where nothing in the project file names it. Running dotnet list package --include-transitive shows the full set, and each entry needs a known compatible version before an upgrade date is set.
Software a vendor maintains needs the same check from the other side. Ask the vendor for its plan and delivery date for moving off .NET 8 or .NET 9, and keep the written answer with the system's record. Until the vendor commits to a date, that system's schedule depends on someone outside the business.
Deployment Type Decides What Moves With the Application
A framework-dependent deployment relies on a .NET runtime already present on the server or in the container image, so that environment needs a .NET 10 runtime before the upgraded application can start there. After the move, a framework-dependent app by default rolls forward to the newest .NET 10 patch installed on the host, so staying current is largely a matter of applying runtime updates. A self-contained deployment carries its own runtime inside the published output. The .NET runtime does not need to be installed separately; operating-system and hosting prerequisites still apply. The application has to be republished to pick up .NET 10, and republished again for every later runtime security patch.
The hosting platform has its own setting to change, whether it is an app service, a functions host, a container platform or a virtual machine image. Build agents need the .NET 10 SDK before a net10.0 project will compile on them, and a repository that pins its SDK in global.json needs that pin updated, or the build will not use the intended toolchain.
Testing and Rollback Before Production
An upgraded application is ready when it has been exercised in a staging environment that resembles production, after the automated tests pass. Systems with thin test coverage need more manual checking, because the suite proves less about them. Moving lower-risk systems first gives the team a tested sequence before the business-critical applications are scheduled.
The rollback plan belongs in the change record before deployment: how to reinstate the previous build, which window is low-risk, and which log entries or health checks would show a problem in the first hour. For a framework-dependent application, reinstating the previous net8.0 or net9.0 build also needs that runtime still present on the server or in the image, so the old runtime stays installed until the rollback window has closed.
Related Reading
For the SDK warnings and roll-forward behavior during the upgrade, read Planning a .NET 10 upgrade and a separate workflow improvement. For a wider view of replacing older systems, read the Legacy Application Modernization Guide.