On November 10, 2026, Microsoft ends support for both .NET 8 and .NET 9. After that Patch Tuesday, neither version will receive security fixes or technical support. Applications will keep running, but every newly discovered vulnerability in the runtime or ASP.NET Core will remain unpatched on those versions. For many organizations this is a double cliff: .NET 8 was the long-term support release that most teams standardized on, and teams that moved early to .NET 9 assumed they had more time. If your portfolio still contains .NET 8 or .NET 9 workloads, the question is no longer whether to upgrade but how to triage, sequence and execute quickly without breaking production. This playbook covers the decision framework, the technical steps and, just as importantly, how to make runtime upgrades a routine part of engineering rather than a recurring emergency.
What Is Changing and Why the Dates Line Up
According to the .NET team’s announcement, .NET 8 was released in November 2023 as a long-term support (LTS) release, and .NET 9 followed in November 2024 as a standard-term support (STS) release. Microsoft extended STS releases from 18 to 24 months of support, which is why .NET 9 now ends on exactly the same day as .NET 8. The recommended destination is .NET 10, an LTS release that shipped on November 11, 2025 and is supported until November 2028. InfoWorld also notes that .NET 11 is expected this November as the next STS release.
Three facts shape your options:
- No paid extension from Microsoft. Unlike some Windows and SQL Server products, .NET does not have an extended security update program from Microsoft. Third-party vendors offer patch support for some versions, but that is a bridge, not a strategy.
- Unsupported software is an audit finding. Frameworks such as PCI DSS, SOC 2 and ISO 27001 generally expect supported, patched software. Running end-of-support runtimes usually requires a documented exception with a remediation date.
- Tooling will move on. Microsoft has said a future Visual Studio 2022 servicing update will mark .NET 8 and .NET 9 components as out of support, and new SDKs, libraries and cloud platform images increasingly target newer runtimes.
The same pattern applies outside the Microsoft ecosystem. Java now ships an LTS release every two years, with Java 25 following Java 21 and Java 17, and major frameworks such as Spring raise their baselines regularly. Node.js and Python also run on predictable lifecycles. Most organizations operate a mix of runtimes, and the lessons of the .NET deadline apply to all of them.
Step One: Build an Accurate Inventory
You cannot plan what you cannot see. Many organizations discover during an end-of-support event that they have no reliable list of which applications run on which runtime. Build the inventory from several angles, because no single source is complete:
- Source repositories: scan project files for TargetFramework values, global.json SDK pins and Dockerfile base images such as mcr.microsoft.com/dotnet/aspnet:8.0.
- Build pipelines: check which SDK versions your CI agents install and which images they push.
- Runtime environments: query cloud services such as Azure App Service, AWS Elastic Beanstalk or container platforms for configured runtime stacks, and scan servers for installed runtimes.
- Container registries: list images built on .NET 8 or .NET 9 base images, including old tags still referenced by deployments.
- Vendor software: identify commercial or partner-built applications that embed .NET and ask suppliers for their .NET 10 roadmap.
Record for each application its owner, business criticality, exposure (internet-facing, internal or batch), runtime version, major dependencies and test coverage. This becomes your upgrade backlog.
Step Two: Triage with a Simple Decision Framework
Not every application deserves the same urgency. A practical triage combines exposure and readiness:
- Upgrade immediately: internet-facing or compliance-critical applications with reasonable test coverage and no blocking dependencies. These are usually straightforward retargets.
- Bridge and upgrade: high-exposure applications blocked by a dependency, such as a third-party library without a .NET 10 build. Consider temporary third-party patch support or compensating controls, and fix the blocker in parallel.
- Scheduled upgrade with accepted risk: low-exposure internal tools and batch jobs. Document the risk, add network isolation if needed and set a firm deadline.
- Retire or replace: applications with little usage or functionality now available in a SaaS product or another system. End of support is an excellent moment to decommission.
Moving from .NET 8 directly to .NET 10 is supported and recommended; there is no need to stop at .NET 9. For most modern ASP.NET Core and worker service applications, the core change is updating the target framework to net10.0, updating packages and addressing breaking changes.
Step Three: Execute the Upgrade
A well-run upgrade follows the same steps for every application, which makes it easy to parallelize across teams.
Prepare
Read the official breaking changes documentation for .NET 9 and .NET 10, since skipping a version means inheriting changes from both. Update the SDK on developer machines and CI agents, and pin it with global.json so builds are reproducible. Make sure you have a baseline: passing tests, recent performance numbers and known error rates in production.
Retarget and Update Dependencies
Change TargetFramework to net10.0 in each project, then update Microsoft.Extensions, ASP.NET Core, Entity Framework Core and other first-party packages to their version 10 equivalents. Update third-party libraries next, checking release notes for compatibility. Central package management makes this much easier across solutions with many projects. Microsoft’s .NET Upgrade Assistant and newer AI-assisted modernization tooling in Visual Studio and GitHub Copilot can automate many mechanical edits, but every change still needs review.
Fix Breaking Changes and Warnings
Compile with warnings visible, because new analyzers often highlight obsolete APIs that will break in future versions. Pay particular attention to serialization behavior, authentication and authorization configuration, Entity Framework query translation, hosting defaults and container image changes, as these areas commonly cause subtle behavioral differences.
Update Containers and Hosting
Move Docker base images to the .NET 10 tags, review whether you can use smaller or chiseled images, and update the runtime stack on platform services. Check that your monitoring agents, profilers and security scanners support the new runtime.
Test and Release Progressively
Run unit, integration and end-to-end tests, then compare performance against your baseline. Release with a canary or blue-green strategy, monitor error rates, latency and memory, and keep a quick rollback path to the previous build. Most teams find that new runtime versions improve performance, but you should verify rather than assume.
Managing Risk for Workloads That Miss the Date
Realistically, some applications will still be on .NET 8 or .NET 9 after November 10. The goal is to make that a conscious, time-boxed decision rather than an accident. For each workload that misses the date, record a risk acceptance signed by the business owner and the security lead, with a specific remediation date and the reason for the delay. Then reduce exposure while the upgrade is in progress:
- Place internet-facing applications behind a web application firewall or API gateway with strict rules, and remove any endpoints that are not needed.
- Restrict network access for internal applications to the minimum set of clients and services.
- Increase monitoring, including runtime security alerts and anomaly detection on authentication and error patterns.
- Track every .NET security advisory published after the deadline and assess whether it affects the unpatched workloads.
- Evaluate third-party patch support only where a hard dependency makes upgrading impossible in the short term, and set an end date for it.
Report the status of these exceptions to leadership monthly. Visibility tends to accelerate upgrades more effectively than any policy document, because owners see their applications on the list.
Estimating Effort Realistically
Effort varies widely by application, so avoid a single per-service estimate. A useful approach is to upgrade three or four representative applications first, one simple API, one with heavy Entity Framework usage, one with complex authentication and one with many third-party dependencies, and measure the actual time spent on retargeting, fixing, testing and releasing. Extrapolate from those measurements to the rest of the inventory. In practice, the time is usually dominated not by code changes but by testing, environment updates and coordination with dependent teams, which is why test automation and templated pipelines have such a large effect on total cost. AI-assisted tools are genuinely useful for the mechanical portion of upgrades, such as rewriting obsolete API calls or updating configuration, but they do not remove the need for regression testing and controlled releases.
An end-of-support deadline is a symptom, not the disease. The real fix is an engineering system in which upgrading the runtime is a routine, low-risk change made every year.
Worked Example: Upgrading a Portfolio of 40 Services
Picture a hypothetical logistics company with about 40 .NET services: customer-facing APIs, internal back-office applications and a handful of nightly batch jobs, most on .NET 8 and a few on .NET 9. The platform team starts by scanning repositories and the container registry, building an inventory in a week. It turns out that 28 services are straightforward ASP.NET Core APIs with decent test coverage, eight depend on an older reporting library, and four are rarely used tools.
The team creates an upgrade template: a branch with the retarget, package updates, base image change and a checklist of known breaking changes, plus an automated pull request that applies the mechanical edits. Squads upgrade the 28 straightforward services in two-week sprints, releasing behind canaries. For the eight blocked services, the team replaces the reporting library with a maintained alternative and, in the meantime, restricts those services to internal networks with additional monitoring. Two of the four rarely used tools are retired, and the other two are upgraded last. Because the process is templated, the effort per service drops sharply after the first few, and the organization gains a reusable path for the next LTS cycle.
Beyond the Deadline: Make Upgrades Routine
The organizations that handle runtime deadlines calmly are the ones that never let versions drift far in the first place. A sustainable model includes:
- A runtime policy: for example, all production applications run on a supported LTS, and teams adopt each new LTS within a defined window after release.
- Automated dependency updates: tools that open pull requests for package and base image updates keep the gap small and expose breaking changes early.
- Golden paths and templates: platform teams maintain service templates, base images and pipeline definitions so upgrades happen in one place and flow to all services.
- Strong test automation: reliable automated tests are what make frequent upgrades safe. Treat test coverage on critical services as a prerequisite for fast upgrades.
- Lifecycle visibility: dashboards showing runtime versions and end-of-support dates across the portfolio give leaders early warning.
- Budgeted capacity: reserve a small, predictable share of engineering capacity for maintenance so upgrades are planned rather than squeezed in.
Choosing between LTS and STS releases is also a policy decision. LTS releases, now including .NET 10 through November 2028, suit most enterprise applications. STS releases give earlier access to features but require upgrading roughly every two years. Some teams adopt STS for internal tools to learn early, then standardize production on LTS. Whichever policy you choose, write it down, align it with your security and compliance requirements, and make sure product owners understand that runtime currency is part of the cost of owning software, not an optional technical chore that competes with features. When maintenance is framed as risk reduction with a clear business owner, it becomes far easier to protect the capacity it needs in quarterly planning.
What About .NET Framework and Legacy Applications?
The November 2026 deadline applies to modern .NET, not to .NET Framework 4.x, which follows the support lifecycle of the Windows versions it ships with. Many enterprises still run significant .NET Framework estates, including Web Forms, WCF services and Windows-only libraries. Those applications are not facing an immediate cliff, but they carry growing costs: limited cloud-native hosting options, Windows-only infrastructure and a shrinking talent pool. Migrating .NET Framework applications to modern .NET is a larger effort than a version upgrade, often involving replacing WCF with gRPC or REST, moving from Web Forms to modern front ends, and refactoring configuration and dependency injection. AI-assisted modernization tools have made this more tractable, but it should be planned as a modernization project with its own business case.
Common Pitfalls
- Upgrading the application but forgetting the container base image or the platform runtime stack.
- Assuming a clean build means no behavioral change, without regression and performance testing.
- Ignoring transitive dependencies that pin older framework packages.
- Leaving vendor-supplied applications out of the inventory.
- Treating third-party extended support as permanent rather than as a short bridge.
- Doing all upgrades as a one-time crash project and then letting versions drift again.
Conclusion
The end of support for .NET 8 and .NET 9 on November 10, 2026 is a firm, well-publicized deadline, and for most modern applications the move to .NET 10 is a manageable retarget, update and test cycle. Start with an accurate inventory, triage by exposure and readiness, use a repeatable upgrade template and release progressively. Then use the experience to build the policies, automation and platform practices that make the next upgrade, whether .NET 12 or the next Java LTS, an ordinary sprint task instead of a fire drill.
How Hanoi Technology Can Help
Hanoi Technology helps teams inventory their .NET and Java portfolios, run templated runtime upgrades and set up the automation that keeps applications on supported versions.