.NET 8 and .NET 9 are expiring: The upgrade roadmap to .NET 10 LTS

Get advice now!

The date is set, and it is closer than many company calendars reflect: On November 10, 2026, support for .NET 8 and .NET 9 ends – for both versions on the same day. From then on, Microsoft will no longer provide security updates, servicing releases, or technical support. The applications will continue to run, but any vulnerabilities discovered in the runtime thereafter will remain unpatched.

For companies whose website, portal, or custom software is based on .NET 8 or 9, this is less a technical footnote and more a matter of operational security and compliance. This article explains what will specifically happen on the deadline, why .NET 10 LTS is the right target, what the upgrade involves in practice – and what a realistic schedule for the remaining weeks looks like.

Table of Contents

• TLDR
• What specifically happens on November 10, 2026
• Why .NET 10 LTS is the right target – and not .NET 11
• The Umbraco factor: CMS version and .NET version are linked
• What a .NET 10 upgrade involves in practice
• The roadmap until November
• How Cyber-Solutions supports customers with the .NET 10 upgrade
• Conclusion: You don’t start an upgrade in November

TLDR

• .NET 8 (LTS) and .NET 9 (STS) both reach end of support on November 10, 2026 – after that, there will be no more security patches.
• The recommended target is .NET 10 LTS, supported until November 2028. .NET 11 will be released in November 2026 but is an STS version with shorter support.
• Umbraco 13 runs on .NET 8 and reaches end of life itself on December 14, 2026. The path leads to Umbraco 17 LTS on .NET 10 – including a new Backoffice.
• The runtime upgrade is rarely the problem. Effort arises from third-party packages, custom code, hosting environment, and tests.
• Those who inventory and prioritize now will migrate in an orderly manner. Those who start in November will migrate under pressure.

What exactly happens on November 10, 2026

Microsoft has clearly communicated the date: On November 10, 2026 – a Patch Tuesday – the support periods for .NET 8 and .NET 9 end simultaneously. For .NET 8, the three years of Long-Term Support since November 2023 will be over. .NET 9 as a Standard-Term-Support version ends after 24 months on the same day. Both versions may receive a final update on that day, then nothing more.

What this means is basically simple: applications will continue to run, and their behavior will initially not change. What changes is the risk situation. Security vulnerabilities in the runtime, ASP.NET Core, or base libraries discovered after the deadline will remain unpatched in .NET 8 and 9. For publicly accessible websites, portals with login, and applications with customer data, this is a situation no IT manager wants to be responsible for long – and auditors, insurers, and compliance requirements increasingly ask about it explicitly.

There is also a practical effect: Microsoft announces that Visual Studio 2022 will mark the .NET 8 and .NET 9 components as "out of support" in the future. Third-party library and platform providers typically withdraw their support in line with the Microsoft lifecycle. Staying on an unsupported runtime means gradually losing the ability to update dependencies.

Why .NET 10 LTS is the right target – and not .NET 11

Microsoft recommends upgrading to .NET 10. The version has been available since November 2025, carries the LTS label, and will be supported until November 2028. For platforms that need to run stably for years, this is the decisive point: three years of planning security instead of another forced upgrade after two years.

The question about .NET 11 often comes up in conversations because the version is expected to be released in November 2026 – almost simultaneously with the end of support for 8 and 9. For operating enterprise platforms, it is still not the better choice. .NET 11 is an STS version with 24 months of support according to Microsoft's release rhythm. Those who rely on it will face another upgrade at the end of 2028 – without being significantly more secure than with .NET 10. For web platforms, CMS installations, and custom software in enterprise use, switching from LTS to LTS is the calmer path.

Those still running older versions like .NET 6, whose support already ended at the end of 2024, should not delay the upgrade any longer and aim directly for .NET 10 instead of intermediate steps.

The Umbraco factor: CMS version and .NET version are linked

For CMS-based platforms, the .NET version is not a free choice but tied to the CMS version. Umbraco explicitly aligns its major releases with the .NET rhythm: Umbraco 13 LTS is based on .NET 8, Umbraco 16 on .NET 9, Umbraco 17 LTS on .NET 10.

This results in a double deadline for many Umbraco operators. Umbraco 13 – the widespread LTS version of recent years – reaches end of life itself on December 14, 2026. Umbraco 16 on .NET 9 has been unsupported since June 2026. The stable target is Umbraco 17 LTS on .NET 10, supported until November 2028 – in step with the .NET base.

The path from Umbraco 13 to 17 is more than a framework change. With Umbraco 14, the Backoffice was completely rebuilt. Individual Backoffice extensions like custom property editors, dashboards, or sections from the 13 world do not simply continue in the new architecture but must be reimplemented. The frontend, content structure, and most standard functions usually migrate in an orderly manner. Operators with many Backoffice customizations on Umbraco 13 should realistically plan for more effort here – those closer to the standard significantly less.

The same principle applies to Xperience by Kentico: new versions follow the current .NET base, and knowing which version runs in your own project is a top priority in the inventory. Even for custom software without CMS, it is worth looking at dependencies: libraries for authentication, PDF generation, reporting, or interfaces have their own compatibility matrices that influence the upgrade path.

What a .NET 10 upgrade involves in practice

The often-quoted phrase "just set the TargetFramework to net10.0" is true – and describes only the smallest part of the work. Projects repeatedly show that the effort is not in the runtime itself but in what has grown around it.

First are the dependencies: NuGet packages that need updating for .NET 10, packages that do not yet have a compatible version, and packages whose providers no longer develop them. Each of these categories requires a decision – update, replace, or remove. Then the breaking changes between versions: they are manageable and documented per release but often affect exactly the places where custom code deeply interacts with framework behavior – middleware, serialization, authentication, background services.

The third block is the environment: build pipelines, container images, App Service configurations in Azure, local development environments, and servers where the new runtime is installed and the old one replaced. And finally, testing. An upgrade without regression tests is an upgrade on suspicion. Where automated tests are missing, at least a reliable manual test plan is needed for critical paths: login, forms, interfaces, search, checkout.

The effort is therefore not a flat rate. A lean application with current dependencies can be converted quickly. A grown platform with many integrations and older packages requires its own small project. But this can be estimated in advance – if you do it.

The schedule until November

From today, there are about two months until the deadline. This is sufficient for most applications if the process is structured – and tight if starting only in October. A proven schedule looks like this:

It starts with the inventory: which applications run on which .NET version? Which CMS version is behind it? Which dependencies are critical? Then prioritization by exposure and business relevance – publicly accessible systems with login or customer data first, internal tools afterwards. For each application, the effort is estimated and the time window set.

The conversion itself begins in a staging environment: raise TargetFramework, update dependencies, make build runnable, work through breaking changes. Then regression tests, release by the business side, and a planned rollout with fallback option. Where the application is already facing a major step – for example Umbraco 13 to 17 – the .NET upgrade is part of this project, not a separate preliminary step.

It is important to align the schedule with real conditions: release windows of business units, change freezes during year-end business, availability of developers. Those who plan these factors now will experience November 10 as a date in the calendar – not as an event.

How Cyber-Solutions supports customers with the .NET 10 upgrade

Cyber-Solutions, as a Microsoft Gold Partner, Umbraco Platinum Partner, and Kentico Partner, supports numerous .NET-based platforms in ongoing operation – from corporate websites to portals to custom software. Currently, we are proactively contacting customers whose applications run on .NET 8 or 9 and provide a concrete effort estimate and time window per application.

The approach is always the same: inventory of applications and dependencies, estimate per system, upgrade in staging including package updates and hosting environment adjustment, regression tests, and orderly rollout. For Umbraco platforms, we additionally assess the path to Umbraco 17 LTS and the share of Backoffice extensions that need to be reimplemented. Companies that do not operate their .NET applications with us can request the same upgrade check as an independent service.

Conclusion: You don’t start an upgrade in November

November 10, 2026, is not a surprising date but a lifecycle step announced years ago. The goal is clear: .NET 10 LTS, in connection with Umbraco 17 LTS for Umbraco platforms. The effort depends less on the runtime than on dependencies, custom code, and environment – and can now be reliably estimated. Those who make this estimate in the coming weeks decide the order and timing themselves.

Request upgrade check now