A developer on my team — let's call him Nico, because that's not his real name — spent an afternoon trying to add a NuGet package to a project running .NET Framework 4.8. Nothing exotic: a well-known library for working with JSON, the kind of thing you'd expect to just work. It didn't. The package only shipped for .NET 6 and later. He tried an older version. Also dropped. He went back two more major versions before he found one that still technically supported Framework, and even that one carried a warning that it was no longer receiving updates.
Nico came to me confused. "I thought .NET Framework was still supported?" He wasn't wrong. It is. Microsoft still ships security patches for it. It still runs reliably on current versions of Windows. It will likely keep working, quietly, for years. But "supported" and "evolving" are two different promises, and the gap between them is exactly what Nico ran into that afternoon.
This article is about that gap: what "still supported" actually means for .NET Framework, why it quietly gets wider every year even though nothing is obviously broken, and why that's a planning conversation, not a fire drill.
Two different promises, often confused
When people say .NET Framework is "supported," they usually mean one specific thing: Microsoft will patch security vulnerabilities, and it will keep running on the Windows versions that are themselves still supported. That promise is real, and it's not going away anytime soon — .NET Framework 4.8 ships as part of Windows itself, and Microsoft has been explicit that it isn't pulling the plug.
What that promise does not include is new features, new libraries, or active performance work. All of that — every new language feature in C#, every new library the open-source .NET community builds, every round of performance tuning Microsoft's engineers do to the runtime itself — goes into modern .NET only. .NET Framework stopped receiving new capability years ago. It is finished, in the sense a sealed book is finished. It still opens exactly the same way every time you pick it up. Nobody is going to add a new chapter.
That is the actual meaning of "frozen." Not abandoned, not insecure, not urgent — just permanently as it is today, while everything else in the ecosystem keeps moving.
Why the gap grows quietly, year by year
Here's what makes this easy to underestimate: nothing about a frozen platform announces itself. The application still runs on Monday morning exactly like it ran last Monday. There's no error message that says "you are now three years further behind than you were." The cost shows up sideways, in small moments like Nico's afternoon, and it compounds in a few predictable ways.
First, fewer new libraries support it. Package authors target where the audience is, and the audience moved to modern .NET years ago. Every year, the share of the ecosystem that still bothers to ship a .NET Framework build shrinks a little further.
Second, fewer new developers know the old patterns well. Someone who started their career in the last five or six years learned ASP.NET Core, not Web Forms. They learned dependency injection the modern way, not the patterns .NET Framework projects tend to lean on. They can learn Framework, of course — but it's a second thing to learn, not their default, and that shows up in ramp-up time and in hiring (a topic that deserves, and gets, its own article).
Third, hosting keeps narrowing. .NET Framework ties you to Windows. Modern .NET runs on Windows, Linux, and in lightweight containers, which is most of where cheap, flexible hosting has gone. Staying on Framework doesn't make your current hosting disappear, but it does mean you're not able to take advantage of where the hosting market has been heading.
None of these show up as an incident. They show up as a slowly shrinking set of options, available to you only if you look for them.
What this doesn't mean
It does not mean your .NET Framework application is a ticking bomb. If it's stable, if it does its job, if nobody on your team is losing sleep over it, there is no reason to treat this like an emergency. I've worked on systems that ran on Framework for a decade without drama, including the core booking and content systems I maintained for years at an online travel agency — real production software, serving real customers, every single day, on a platform plenty of people were already calling "legacy" while it quietly did its job.
What it does mean is that this is worth a deliberate decision rather than an accidental one. Not "we must migrate right now," but "we should know, on purpose, whether this system is one we keep running as-is, one we gradually move forward, or one that's approaching the point where staying put costs more than moving."
Reading the signal correctly
The honest test isn't "is it still supported?" — yes, it is, and will be for a while. The better questions are closer to: is this system still easy to hire for? Are the libraries you need for your next feature actually available on this platform? Is your hosting getting more expensive or more limited because of where you're stuck? Those answers change slowly, which is exactly why they're easy to miss until a moment like Nico's NuGet search forces the question.
That afternoon didn't cost us anything beyond an hour of searching for a workaround. But it was a clear, small signal of where the platform actually stands today, and those signals are worth paying attention to before they stack up into a bigger decision made under pressure. An audit is the deliberate version of that same check — a structured look at exactly where a system sits on that spectrum, before anything forces the question.