Picture this: your IT team gets a call on a Friday afternoon. A critical application is throwing errors, users can’t access what they need, and the developer who built the system left two years ago. The code is running on a version of .NET that Microsoft stopped adding features to years ago. Nobody in the room knows exactly what it will take to fix it. The weekend is about to get a lot longer.
That scenario is playing out in hospitals, school districts, and government agencies more often than most leaders realize.
Microsoft has been direct about this for years: the old .NET Framework platform — the one that powered most Windows applications built before 2019 — is a dead end. The replacement, simply called .NET, is where all active development and security investment goes.
What that means in practice depends on which version you’re running. Older Framework versions (4.6.1 and below) are fully out of support — no security patches, no bug fixes, nothing. Newer Framework versions (4.7, 4.8) still receive basic security updates tied to the Windows lifecycle, but Microsoft has committed to no new features and no future investment. If you migrated to .NET 5, 6, or 7, all three are already past their end-of-support dates, with no patches of any kind.
Even more recent versions have a tighter timeline than most people realize. Both .NET 8 and .NET 9 reach end of support on November 10, 2026. .NET 8 is a Long Term Support release; .NET 9 is Standard Term Support. Different tracks, same expiration. That means teams on either version have roughly five months to plan and execute a move to .NET 10 before they’re in the same boat as everyone else.
The bottom line: if you’re not on .NET 10, you’re either already out of support or you will be before the year is out. Whatever vulnerabilities get discovered after a version’s end date, you’re living with them.
For a healthcare provider handling patient records, a school district managing student data, or a government office running public-facing services, that’s not just a technical problem. It’s a compliance and liability problem.
The reasoning sounds sensible: “It’s working fine. We’ll deal with it when we have to.” The problem is that “nothing is on fire” isn’t the same thing as “everything is okay.”
Legacy .NET applications accumulate quiet risk over time. Integrations break when other systems update. Security audits flag the old runtime. Developers with the right experience get harder to find. When the application finally fails, the scramble is significantly more costly and disruptive than a planned migration would have been.
A school system that moved its enrollment platform to modern .NET last year didn’t do it because something broke. They did it because a compliance review was coming and they didn’t want to explain to auditors why they were running software the vendor no longer supported. That’s a conversation worth avoiding.
First, take an inventory. Many organizations are surprised to find outdated .NET versions tucked inside applications that haven’t been touched in years — including third-party tools they assumed the vendor was maintaining.
Second, check where you stand on the support timeline. Microsoft publishes end-of-support dates for every .NET version. Not all versions are equal — some receive long-term support, others don’t. If you’re not sure what you’re running or when your coverage expires, that’s worth finding out this week, not next quarter.
Third, scope the work before you’re forced to. Modernizing a .NET application doesn’t always mean a full rewrite. Some applications migrate with relatively straightforward changes; others need more significant rearchitecting. The difference matters enormously for budget and timeline — and you won’t know which category you’re in until someone takes a look.
.NET modernization is well-understood, documented work. The path from legacy to current is clear, and organizations that take it on deliberately — on their own schedule, before something breaks — almost always have a better experience than those who wait for a crisis.
At Sunnet, this is work we do regularly. We help teams get from “we should probably deal with this” to a concrete plan — and we know where the surprises tend to hide.
You don’t have to figure it out alone. But the best time to start is before the Friday afternoon call.