What is new in .NET 11, and should you move from .NET 10?
A fair tour of .NET 11 and C# 15 as released on 10 November 2026, the breaking changes to read first, and a decision guide for production teams on .NET 10.
· 7 min readThis month you have heard that .NET 8 and .NET 9 are going out of support. Your own application was built years ago, and someone has said it runs on ".NET Framework". The natural question is whether it is affected too.
The answer depends on a version number, and it is more reassuring than many people expect. .NET Framework follows different rules from .NET 8 and .NET 9, and most applications on a recent version of it are not facing an end date of their own. A few are. This article explains how to tell which group you are in and what your options are. It is written as of 30 October 2026.
.NET Framework and modern .NET: the difference
Both are Microsoft platforms for building software in languages such as C#. They are separate products.
.NET Framework is the original platform, first released in 2002 and built into Windows. Its latest versions are 4.8 and 4.8.1. It runs only on Windows.
.NET (without "Framework") is the newer platform, which began as .NET Core. It is released every November, runs on Windows, Linux and macOS, and has the version numbers you have been reading about: .NET 8, 9 and 10. Our article on .NET 8 and .NET 9 end of support covers those.
Applications built for one do not simply run on the other. Moving between them is a project called a port, which we come to below.
How .NET Framework support works
Microsoft's .NET Framework support policy treats .NET Framework 4.5.2 and later as a component of the Windows operating system. Components receive the same support as their parent product, so these versions follow the lifecycle of the Windows they are installed on. For 4.8.1, the policy says that as long as it is installed on a supported version of Windows, it continues to be supported.
In practice that gives a simple rule. If you are on .NET Framework 4.8 or 4.8.1, the question to ask is whether the Windows version underneath is still supported. The framework version itself has no separate end date listed.
The same policy page lists the exceptions and the older versions:
| Version | Position on Microsoft's policy page |
|---|---|
| 4.8.1, 4.8 | Supported, with no separate end date listed |
| 4.7 to 4.7.2 | Supported, with no separate end date listed |
| 4.6.2 | Support ends on 12 January 2027 |
| 4.6.1, 4.6, 4.5.2 | Support ended on 26 April 2022 |
| 3.5 SP1 | A separate product with its own date: support ends on 9 January 2029. It runs alongside 4.x rather than being replaced by it |
If you are on 4.6.2, 4.6.1, 4.6 or 4.5.2, this is the part that needs attention. A 4.6.2 application has about ten weeks left from today. The ones that ended in 2022 are already out of support, and a quiet application running on one of them for years may simply have been forgotten.
The Windows connection
Because the framework follows Windows, the operating system matters as much as the application. Check the lifecycle date of every server and workstation that runs it.
Windows Server 2016, for example, reaches the end of its extended support on 12 January 2027, according to Microsoft's list of products ending support in 2027. That is the same date as the end of .NET Framework 4.6.2, so an application on both could meet two end dates at once. We covered an earlier case in our article on Windows Server 2012.
Microsoft's lifecycle page for each Windows version is the authority, so look yours up and note the date down.
First, find out what you have
You may not know the version. Ask whoever looks after the system for three facts, in writing:
- the .NET Framework version installed on each machine that runs it
- the Windows version of each of those machines, and where they are (your server, a hosting provider, a PC under a desk)
- whether it has any automated tests
Ask for the installed version, not just the version the application was built for. Newer 4.x versions replace older ones in place, so an application built for 4.6.2 may already be running on a supported 4.8, and it is the installed version, together with Windows, that the support dates apply to.
Those three answers fit on a postcard and tell you which situation you are in.
Your options
There are three realistic routes. The right one depends on how long the system needs to live and how it is used.
1. Stay on .NET Framework, and keep it supported. If the application is on 4.8 or 4.8.1 and runs on a supported Windows version, this can be a perfectly reasonable position. You are not out of support. You need to keep Windows patched and plan the operating system's own end date. If you are on 4.6.2 or earlier, updating the machine to 4.8 or 4.8.1 is the first step (4.8 is the latest that Windows Server 2016 and 2019 can install). One catch: a machine still on 4.6.2 is usually Windows Server 2016 or older, and on Windows Server 2016 the framework's support ends with the operating system on 12 January 2027 whatever version you install. There, updating the framework does not move the date; the server has to move too. Microsoft expects applications built for earlier 4.x versions to keep running without being rebuilt, so this is usually a much smaller change than a full port, though it still needs testing.
2. Port to modern .NET. This moves the application to .NET 10, the current long-term release, so it can run on a platform that is released and supported every year, and on Linux if you wish. What a port involves depends on the application. Microsoft's overview of porting from .NET Framework to .NET lists the technologies that have no direct equivalent and the dependencies that need checking. Applications with older web technologies or Windows-specific features take longest. Microsoft's current recommended tool, the GitHub Copilot upgrade agent (also called app modernization), can help with assessment and changes, but a person needs to review the results and the tests must pass before release. We supply Microsoft licences and know these tools well, but the right choice depends on your application.
3. Replace it. For some systems the honest answer is that the business need has moved on. A bought product or a new build may serve better than a port, especially if the application is small, unloved or hard to change.
How to decide
Three questions usually settle it:
- How long will the system live? If it will run for another two or three years and then go, staying put with a supported Windows may be enough. If it will run for ten, a port is worth planning.
- Does it need to change? If new features are wanted, a platform that is still evolving is easier to work with.
- How risky is a change? This is where tests matter. With automated tests, any option is cheaper and safer, because you can see immediately whether behaviour has changed. Without them, adding tests first is usually the right investment. Our article on adding tests to code nobody dares change explains the approach for your technical team.
If the system is moving off an old server anyway, a move to Azure can be combined with the port, rather than done as two projects.
A sensible first step
Find the three facts from the list above for each .NET Framework application you have: the installed framework version, the Windows version and whether it has tests. If any machine still has 4.6.2 installed, put its date, 12 January 2027, in the diary and decide this quarter whether to update it to 4.8 (and, on Windows Server 2016, move to a newer Windows Server as well), port the application or replace it.
If you would like an engineer to check the position for one system, a software health audit reports on support status, hosting and risks in plain English. Eastpoint looks after .NET Framework applications as well as modern .NET through software care.
