.NET 8 and .NET 9 end of support on 10 November: what it means

On 10 November, two weeks from now, .NET 8 and .NET 9 go out of support. Perhaps your developer or your IT support company has raised it with you. You would like to know whether it is a problem, how big a problem, and what you are being asked to decide.

For most organisations this is a planning matter rather than an emergency. Nothing stops working on 10 November. What stops is the flow of security fixes for that version of .NET, and that gradually changes the risk you are carrying. This article explains what is ending, what to find out first, and the choices in front of you. It is written as of 27 October 2026.

What is ending, and when

.NET is the Microsoft platform that a large amount of business software is built on, in the C# language. Microsoft publishes its dates on the .NET support policy page, and the position is this:

Microsoft gives long-term releases three years of support and standard-term releases two. Because both versions end on the same day, the date is getting a lot of attention. For context, .NET 6 ended on 12 November 2024. Microsoft also announced the 10 November date for .NET 8 and .NET 9 on its .NET blog on 29 June 2026.

.NET 10 is the current long-term release, so it is the sensible destination for most organisations.

What "end of support" means in practice

Microsoft's own wording is that after the date it no longer provides fixes, updates or online technical assistance. Its blog post is plain that existing applications will carry on running, and also that staying on an unsupported version means exposure to security vulnerabilities that will not be patched.

So on 11 November your application works exactly as it did on 9 November. The difference is that if someone discovers a weakness in .NET 8 next year, no fix will be released for it. The longer an application stays in that position, the more such weaknesses can accumulate. Our article on what "out of support" means goes through this in more detail, including what auditors and insurers tend to make of it.

First, find out which version you use

You may not know. Many organisations have several applications, built at different times, on different versions. Three ways to find out:

• Ask whoever looks after the system, and ask them to put the answer in writing, with the version and the hosting arrangement.
• Look at the supplier's documentation or support portal, if the software was bought in.
• Commission a short audit, which establishes this and the other facts that matter at the same time.

If a supplier built and maintains the application, Microsoft's advice is to ask them for a version that targets .NET 10.

Your choices

There are broadly three, and they are not exclusive.

1. Upgrade to .NET 10. This is the usual answer. For many applications the change is modest: the project is pointed at the newer version, components are updated, and the application is tested and released. Others take longer, particularly if they use older libraries or have no automated tests. A technical guide to upgrading from .NET 8 to .NET 10, for the person doing the work, follows later this week.

2. Check what your hosting platform does after the date. Microsoft offers no paid extension for .NET, so no host can supply official fixes once support ends; what differs is how the platform treats an old runtime. Azure App Service, for example, follows Microsoft's own .NET dates. Its language support policy says that apps on a runtime past its end of support keep running unchanged, but App Service can't provide security patches or related customer support for that runtime. Check your own host's notices so you know whether anything will change on its side, but treat this as information, not cover. We supply Microsoft licences and know these products well, but the right answer depends on your hosting.

3. Plan a short, dated exception. If an upgrade cannot happen by 10 November, that is not unusual. Write down which applications are affected, the reason, who owns the decision, and the date by which each will move. An exception with an owner and a date is a managed risk. An unexamined one is simply a gap.

What the work involves, and why tests matter

An upgrade has four parts: update the version, update the components the application depends on, check that behaviour has not changed, and release it safely. The third part is where cost and risk sit.

If the application has automated tests, checking behaviour takes minutes and the answer is clear. If it has none, someone has to click through the system by hand and hope they spot a difference. That is slower and less reliable. For systems with no tests, adding what are called characterisation tests first makes the upgrade cheaper and the result far more trustworthy. Our article on adding tests to code nobody dares change explains the idea for a technical reader.

How to brief the person who looks after it

If you are handing this to a developer or an IT lead, these questions give you a useful answer back:

• Which applications do we have on .NET 8 or .NET 9, and where do they run?
• Which are business-critical, and which could wait a few weeks?
• Do they have automated tests?
• What is your estimate to move each one to .NET 10, and what is the main uncertainty?
• Who signs off the release?

Ask for the reply in writing. It becomes the start of your roadmap for the system.

A sensible first step

This week, get a one-page list of every application on .NET 8 or .NET 9, with the hosting and the person responsible for each. Mark which ones the business could not do without. That list is the basis for every decision above, and it takes a short conversation rather than a project.

If nobody can produce it, or the person who knew has left, a software health audit establishes the position for one system. Eastpoint looks after .NET (C#) applications, including .NET Framework, through software care, and we would be glad to talk it through.