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 readSomewhere in your organisation there may be an application that runs on an old Windows server. It has run for years, people use it every day, and nobody has had a reason to touch it. Today is the date Microsoft has set for the last security updates for that server, if it is covered by Microsoft's paid Extended Security Updates or runs in Azure. If you never paid for them, the position is starker: the server has had no security fixes since 10 October 2023. Either way, it is worth a few minutes of attention.
Nothing will stop working this afternoon. The server will start, the application will open and your staff will carry on. What changes is that from today, any new security weakness found in Windows Server 2012 or 2012 R2 will not get a fix from Microsoft. This article explains what that means in plain terms, and the sensible routes from here.
What the three stages mean
Microsoft supports its server products in stages. For Windows Server 2012 and 2012 R2 the dates, taken from Microsoft's lifecycle record and its Extended Security Updates overview, are:
| Stage | What you get | Ended |
|---|---|---|
| Mainstream support | Security fixes, other updates and support for incidents and warranty claims | October 2018 |
| Extended support | Security fixes at no extra cost, but no new features | 10 October 2023 |
| Extended Security Updates (ESU) | Only critical and important security fixes, paid for outside Azure and included for servers in Azure | 13 October 2026, today |
The fixed lifecycle policy describes the first two stages in general. ESU was a final, time-limited extension for organisations that needed more time to move, and the overview gives its end date as 13 October 2026.
So today is the last day of security fixes for this version of Windows Server. Microsoft's overview is plain about what follows: once the ESU period ends it will stop providing updates, and it recommends moving to a more recent version of Windows Server as soon as possible.
Why "it works fine" is not the whole picture
An application can work perfectly well and still be exposed. New weaknesses in Windows are found every month across all versions of the product. On a supported server they are fixed by a routine update. On an unsupported one, the fix never arrives, and the weakness stays for as long as the server runs.
Nothing dramatic is likely to happen today. The concern is a gap that widens month by month, while the application, and whatever data sits on it, depends on a server that cannot be patched. Auditors, insurers and customers often ask about this, and "it is out of support" is not a comfortable answer to give them.
This is a common situation, and it is manageable with a plan.
The routes from here
Microsoft's overview describes upgrading in place, building new servers on a supported version and moving to Azure. In practice, for one business application, the choices are:
- Move it to a supported Windows Server. The application is installed on a newer version of Windows Server, on your own hardware or a hosted one.
- Move it to a supported Azure service. That might be a virtual machine running a current Windows Server, or, where the application suits it, a managed Azure service that removes the server from your care altogether.
- Retire it. Some applications are no longer needed, or their job is now done by something else. This is worth asking honestly, because it is the cheapest route when it applies.
We supply Microsoft licences and know Azure well, but the right route depends on the application, and a supported server of your own is often the sensible answer.
Two things are often suggested as shortcuts. Taking the server off the internet, or putting it behind a firewall, does reduce who can reach it, and it is a reasonable stopgap while you plan. It is not a fix: the server is still unpatched, and anything on your internal network, including a laptop that picks up the wrong email, can still reach it. Treat it as a way to buy time, with a date attached.
The other is to leave things as they are and decide later. That is a decision too, and it is better made deliberately, with the risk written down and someone named as owning it.
The catch: the application usually has to change
Moving a server is rarely just moving a server. A bespoke application written for Windows Server 2012 may depend on older versions of .NET Framework, an old database engine, a component that is no longer sold or settings that only its original developer understood. When it is installed on a newer server, something often behaves differently.
This is where software with no automated tests and no current documentation causes the most trouble. If nobody can say quickly whether the application still does the right thing after the move, every step takes longer and costs more. If your developer has left, that knowledge may not exist anywhere. Plan for some time to find out what the application needs before choosing a route.
Questions to ask this week
You do not need to be technical to ask these, and a short answer to each is enough to start.
- What is on the server? One application or several? Is there a database on it? Does anything else, such as the finance system or a website, depend on it?
- Who can reach it? Only people in the office, remote staff, customers, or the open internet?
- What happens if it is unavailable for a day, and for a week? This tells you how much to spend on moving it carefully.
- Is there a backup, and has anyone restored from it?
- Who looks after it? A named person inside the business, or at a supplier, who would act if something went wrong.
A sensible first step
This week, write down the servers that run Windows Server 2012 or 2012 R2, the application each one hosts, who uses it and who owns the risk. One page is plenty. It turns a vague worry into a short list, and it is the document everything else starts from.
Then choose a route for each application, starting with the one that matters most to the business. If the application's builder has gone, or you are not sure what it needs in order to move, ask for an independent view before committing to a route.
Dates like this one belong on a roadmap, not in someone's memory. If you do not yet have a view of the key dates for your systems, our article on a one-page technology plan is a good starting point.
If you would like to know where your own system stands, a software health audit looks at one application and gives you a clear picture of its state, so the choice of route rests on facts. If the answer is a move to Azure, our cloud migration work covers bespoke and legacy applications, and our software care service looks after them afterwards.
