On November 10, 2026, Microsoft ends free support for both .NET 8 and .NET 9. After that date, these versions stop receiving security patches, bug fixes, and official technical support. The software keeps running, but it stops being protected. For most businesses this is a planning problem, not an emergency, and there is still time this year to handle it in an orderly way.
Microsoft recommends moving to .NET 10, the current long-term support release, which is supported through November 2028. The move from .NET 8 or .NET 9 to .NET 10 is usually far smaller than a legacy rewrite, but it still needs to be found, owned, tested, and scheduled. This article is written for the person who signs off on that work, not only the developers who do it.
This Is Modern .NET, Not .NET Framework
The word .NET covers two different products, and confusing them causes both false panic and missed risk. Modern .NET, the versions numbered 8, 9, and 10, is the cross-platform product Microsoft ships every November. The November 10, 2026 deadline applies to .NET 8 and .NET 9. The older .NET Framework, the 4.x line that only runs on Windows, is a separate product with its own, longer support lifecycle tied to Windows itself. It is not covered by this deadline.
So the first question is simple: which product does each system actually use? If an application targets .NET 8 or .NET 9, the November 2026 date is real and worth planning around now. If it targets .NET Framework 4.8, this specific deadline does not apply, though modernization may still be worth a conversation for other reasons. Getting this distinction right for each system prevents wasted effort and keeps attention on what genuinely needs to move.
Start With An Inventory
You cannot plan an upgrade for software you have not listed. The goal of the first step is a single inventory of everything that runs on .NET 8 or .NET 9, including the systems that are easy to forget: public web applications, internal admin tools, APIs, background and worker services, scheduled jobs, desktop applications, mobile app backends, and small utilities that quietly keep an operation running.
For each system, record the target framework version, where it is hosted, how it is deployed, and how important it is to the business. The target version usually lives in the project configuration, and the running version can be confirmed on the servers, containers, or cloud services that host it. The output is not a technical trophy. It is a business list that shows what is affected, what is critical, and where the unknowns are.
Assign Ownership
Every system on that list needs a named owner. Ownership answers the practical questions that stall upgrades: who decides when the work happens, who tests the result, who approves the deployment, and who is called if something looks wrong afterward. Some systems are owned by an in-house team, some by an outside partner, and some by a vendor who maintains the software on your behalf.
Software with no clear owner is the most common reason a deadline is missed. It is worth resolving ownership early, while there is time to reassign work, rather than discovering the gap in the final weeks.
Check Dependencies, Runtime, And Hosting
An application does not upgrade in isolation. Three layers around it need to move too. The dependency layer is the set of third-party libraries and packages the application relies on; each one needs a version that supports .NET 10, and a rare unmaintained package can become the hardest part of the whole effort. The runtime layer is the .NET version installed on the servers, virtual machines, or container images that run the code. The hosting layer is the platform underneath, whether that is on-premises servers, a cloud application service, serverless functions, or a container platform, each of which has its own supported-runtime settings and its own way of being updated.
Build and deployment pipelines belong in this check as well. The agents that compile and publish the software need the .NET 10 tooling before they can produce the upgraded builds. Listing these layers per system turns a vague upgrade into a concrete set of steps.
Do Not Forget Vendor-Managed Software
Not every affected system is one your team can change directly. Some business software is purchased, licensed, or hosted and maintained by an outside vendor. For those systems, the upgrade is the responsibility of the vendor, but the risk is still yours if they do not act in time.
The practical step is to ask each relevant vendor a direct question: what is the plan and timeline for moving off .NET 8 and .NET 9 before November 10, 2026? A clear answer in writing is worth more than an assumption. If a vendor has no plan, that is useful to know now, while there is still room to press for a commitment or prepare an alternative.
Test, Deploy, And Plan The Rollback
An upgrade is only finished when it is proven safe, not when the code compiles. A dependable pattern is to make the change on a branch, run the automated test suite, and then exercise the application in a staging environment that resembles production. Systems with thin test coverage are worth extra manual checking, because they offer the fewest guarantees on their own.
Plan the rollback before the deployment, not during an incident. Know how to return to the previous version quickly, choose a low-risk deployment window, and confirm that logging and monitoring are in place to catch problems early. A calm, reversible deployment is the difference between a routine upgrade and a stressful one.
Keep Patching Until You Move
Until a system is on .NET 10, it should stay on the latest available patch of .NET 8 or .NET 9. Microsoft releases security and reliability fixes on a monthly cadence, and those fixes still apply right up to the November 10, 2026 end-of-support date. Freezing a system on an older patch to avoid change is a false economy, because it gives up protection that is still being offered for free. Staying current on the existing version is the safest holding position while the upgrade is planned.
A Practical Timeline
With the deadline in November 2026, the work fits comfortably into phases rather than a single scramble:
- First, build the inventory and assign an owner to every affected system. This is the step that makes all the others possible.
- Next, check dependencies, hosting, and vendor commitments, then decide the order of work, usually starting with lower-risk systems to build confidence.
- Then upgrade, test, and deploy system by system, moving from the simpler applications to the business-critical ones as the process proves itself.
- Throughout, keep every system patched on its current version until it has moved to .NET 10, and confirm each upgrade in production before closing it out.
Handled this way, the deadline becomes a scheduled improvement rather than a source of last-minute risk. Starting the inventory early is what creates the room to be deliberate.
Where IKRC Fits
IKRC builds and maintains custom software on the Microsoft stack, so this deadline is familiar territory. We can help at whatever point is useful: producing the inventory of what runs on .NET 8 and .NET 9, sorting out ownership, checking dependencies and hosting, coordinating with software vendors, and carrying out the upgrades to .NET 10 with real test coverage and a rollback plan. That work draws on our .NET development and application modernization experience, and it often touches software integration where an upgraded system has to keep talking to the tools around it.
If you are not sure which of your systems are affected, that is the right first conversation. Call IKRC at 646-783-1441 or email info@ikrc.co, and we can help you turn the November 10, 2026 deadline into a straightforward plan.
Related Reading
For a wider view of upgrading older systems safely, read the Legacy Application Modernization Guide. For what to look for in a long-term .NET partner, read Choosing a C# Development Company.
Need this solved in your software?
IKRC builds the custom systems, integrations, and modernization work discussed in this article.