"We had a business system built a few years ago, but after seeing news that .NET support ends in November 2026, we don't even know whether our system is affected"—we received this inquiry from a general affairs manager at a manufacturing firm. The more smoothly a system runs every day, the less conscious people are that its underlying technology has an expiration date. Yet that deadline is quietly drawing near.
According to Microsoft's official announcement, support for .NET 8 and .NET 9—both widely used as application foundations—will end on November 10, 2026. After this date, neither security patches for newly discovered flaws nor official support will be provided. The system will not suddenly stop running. That is precisely what makes it dangerous: the core peril of this end-of-support (EOL) issue is that systems are left untouched because "they still work," while their defenses quietly fall away. This article outlines what clients need to verify and how to make informed decisions from the buyer's perspective, rather than the developer's.
What specifically happens when support ends
Hearing "end of support" might not immediately make the stakes clear. Breaking down what actually happens reveals three layers of risk.
The first is security. During the support lifecycle, patches are distributed whenever critical vulnerabilities are discovered. Once support ends, updates stop, leaving systems unpatched against new attack techniques. For business systems handling customer data, this directly translates into data breach risk.
The second is business and audit compliance. Client security assessments and various certifications increasingly require organizations to confirm that they do not run unsupported technologies. If your system runs on an EOL foundation, you cannot answer "yes" to this requirement.
The third is the increasing difficulty of future modifications. Over time, surrounding tools and libraries phase out older versions, leading to secondary issues such as being unable to build the project in modern environments when you finally attempt a fix. Inaction only inflates future migration costs. This deterioration caused by "no one looking after the system post-delivery" is an extension of the issues discussed in what clients should look for in maintenance and operations contracts.
Skipping .NET 9 and heading straight to .NET 10 is standard practice
The path forward is upgrading to a newer version. Here, there is one key decision that benefits clients to know upfront.
In .NET, versions are divided into Long Term Support (LTS) releases, which receive extended care, and Standard Term Support (STS) releases with shorter support windows. The retiring .NET 8 is an LTS release while .NET 9 is STS; according to the .NET Blog and analysis from InfoWorld, the next LTS release, .NET 10, will be supported until November 2028.
| Release | Type | End of support |
|---|---|---|
| .NET 8 | LTS (Long Term) | November 10, 2026 |
| .NET 9 | STS (Standard) | November 10, 2026 |
| .NET 10 | LTS (Long Term) | November 2028 |
The takeaway here is straightforward: upgrading from .NET 8 to .NET 9 provides zero extended lifespan, as both share the exact same end date of November 10, 2026. If you are going to invest migration effort, the standard move is to bypass STS .NET 9 and upgrade directly to LTS .NET 10. Technically, most tasks involve repointing project settings to the new version and leveraging Microsoft's migration assistance tools, though actual effort varies significantly depending on the system's scale and custom implementation.
What clients should verify with their development agency
Even if you do not touch code yourself, simply clarifying the following three points with your development agency or maintenance provider will illuminate the path forward.
- Whether your internal system uses .NET 8 or 9. If it does, November 10 is your deadline. It might be built on an entirely different technology stack, so start by confirming the facts.
- The migration estimate and schedule for completion before the deadline. Effort varies depending on whether a straightforward version bump suffices or whether legacy implementations require manual rework. Because costs vary widely based on system scale, always confirm pricing through an individualized quote.
- Determining whether to upgrade or rebuild. For systems that are years old, have numerous unused features, or experience recurring defects, taking this opportunity to rebuild may prove cheaper in the long run. The decision criteria discussed in legacy migration using AI assistance regarding "life extension vs. modernization" serves as a helpful reference.
Working backward from the deadline
November 10, 2026, is a firm deadline. Because migrations require time for testing and production cutover, panicking at the last minute restricts your options. The safest course is to first confirm whether your system is affected, and if so, finalize estimates and schedules with your development agency well before summer.
If you are unsure whether your system is subject to the .NET end of support, want an objective third-party assessment on whether to upgrade or rebuild, or need to map out a schedule leading up to the deadline, feel free to reach out via GleamHub's development, AI, and automation consultation. From auditing current systems to organizing migration strategies, we work alongside you based on your specific situation.
