A date that does not exist
Since version 4.5.2, .NET Framework is no longer a standalone product but a component of Windows. Components inherit the lifecycle of their host. That is why 4.7, 4.8 and 4.8.1 carry no fixed end of support: they are supported for as long as the Windows underneath them is. Windows Server 2025 is still the newest server release, and .NET Framework 4.8.1 ships with it out of the box.
There is one exception. .NET Framework 4.6.2 has a hard end date on 12 January 2027. The jump from 4.6.2 to 4.8.1 is small, because everything from 4.7 up is close to a drop-in replacement. If you are still there, take that step now.
| Version / product | Status | Supported until |
|---|---|---|
| .NET Framework 4.6.2 | Fixed end of support | 12 January 2027 |
| .NET Framework 4.7 - 4.8 | Windows component | Lifecycle of the host OS |
| .NET Framework 4.8.1 | Windows component, final version | Lifecycle of the host OS |
| Windows Server 2025 | Newest release, ships 4.8.1 preinstalled | 14 November 2034 |
| Windows Server 2022 | Mainstream support ends 13 October 2026 | 14 October 2031 |
Supported does not mean future-proof
Support means security updates. Nothing more. .NET Framework 4.8 shipped in April 2019 and was the last feature release. 4.8.1 followed in August 2022 with Arm64 support and accessibility improvements, no new language or runtime features.
That is what the long support promise actually says: your application may keep running. It will not get better. Every language version, every performance improvement and every new API of the past seven years passed .NET Framework by.
Last feature release. Security updates only ever since.
The final version there will ever be.
The outermost end of the runway, if you sit on Windows Server 2025 today.
The ecosystem is not waiting for you
The support table describes what Microsoft will still fix. It does not describe what you can still build with. And that is where the ground has been moving for years.
Four effects, all pointing the same way and all reinforcing each other.
Developer experience
Hot reload, current C# with records, pattern matching, nullable reference types and collection expressions, source generators, the dotnet CLI, test and observability tooling out of the box. Tools are built for modern .NET today; on .NET Framework you are an afterthought at best.
Available developers
Developers pick stacks they can grow in. Anyone entering the field today learns .NET 10, not WebForms and WCF. Every year on .NET Framework shrinks the pool of people willing to maintain your system and raises the price of the ones who stay.
Current standards
OpenTelemetry, containers and Kubernetes, minimal APIs, Native AOT, running anywhere. New standards arrive for modern .NET first and often exclusively. On .NET Framework you get the retrofit, or nothing.
Throughput
The runtime and ASP.NET Core get measurably faster with every release. On modern .NET you pick that up simply by upgrading. On .NET Framework the ceiling is fixed, and the only remaining answer to load is more hardware.
Sooner or later you build everything yourself
This is the part no lifecycle table shows. The libraries you need are built for modern .NET, and the gap keeps widening.
-
EF Core 3.1is the last version of Entity Framework Core that runs on .NET Framework. It has been out of support since December 2022. -
ASP.NET Core 2.1was the last release that could target .NET Framework. From 3.0 on, that door is closed. -
New NuGet packages increasingly target
net8.0and above and skipnetstandard2.0entirely.
What everyone else installs as a package, you write and maintain in house. That cost appears in no support calendar, but it lands every sprint, and it grows.
The question is not whether you upgrade, but how much it hurts each time
Modern .NET is not an end state. .NET 8 and .NET 9 both reach end of support on 10 November 2026. .NET 10 is the current LTS release and is supported until November 2028.
The rhythm is predictable: even-numbered releases are LTS with 36 months of support, odd-numbered ones are STS with 18. That predictability is the prize. Moving from .NET 8 to .NET 10 is a changed target framework and a test run, usually a matter of days. Moving off .NET Framework 4.8 is a project. Make the one-off step and you trade a cliff for a routine.
What these migrations actually look like
We have guided this move several times, in one case around 150 projects stepping onto modern .NET one at a time. The pattern is always similar: take inventory and fix the target version, make shared libraries bridgeable through netstandard2.0, then move path by path while the product keeps shipping.
Which steps make sense in which order, which terms actually matter and where the usual traps sit, we wrote up in full: Migrating .NET Framework 4.8 to modern .NET
The whole thing in one sentence
The deadline is not in the support matrix. It is the day the ecosystem stops shipping anything you can still use, and that day arrives well before 2031.
More .NET services
The migration guide
From .NET Framework 4.8 to modern .NET: the terminology, a six-step roadmap and the traps from real projects.
Read the .NET migration guideDevelopment
ASP.NET Core, Blazor, Angular and React. From the first line to the application in production.
More on ASP.NET Core developmentArchitecture and technical leadership
Architecture reviews, decisions that hold, and a sparring partner for your team.
More on .NET architectureGet In Touch
Let's Build Something Great Together
Have a question or want to discuss a project? We'd love to hear from you. Fill out the form below and we'll get back to you as soon as possible.
You can also reach us directly at [email protected]