If you've searched for .NET Framework 4.8 end of support, you probably expected a date. There isn't one. That surprises people, and it sends some teams into an unnecessary panic and others into an unjustified sense of safety.
The real position is simple, and it's worth knowing exactly, because it changes what you should plan for.
- .NET Framework 4.8 and 4.8.1 have no end date of their own. They're supported as long as the Windows version they're installed on.
- Check each server's Windows lifecycle. Windows Server 2016, for example, leaves extended support on 12 January 2027.
- If you migrate, target .NET 10. Support for .NET 8 and .NET 9 ends on 10 November 2026.
- WCF services and Web Forms pages don't move across as they are. Find them before you size the work.
What Microsoft actually says
Microsoft's .NET Framework support policy puts it this way:
"Beginning with version 4.5.2 and later, .NET Framework is defined as a component of the Windows operating system (OS). Components receive the same support as their parent products, therefore, .NET Framework 4.5.2 and later follows the lifecycle policy of the underlying Windows OS on which it is installed."
And on the latest version:
"As long as it is installed on a supported version of Windows, .NET Framework 4.8.1 will continue to also be supported."
So .NET Framework 4.8 and 4.8.1 have no clock of their own. Their clock is the Windows version they run on.
The date that matters is your Windows Server
That turns a framework question into an infrastructure question. A .NET Framework 4.8 application is supported for exactly as long as the Windows it's installed on.
Take an application running on Windows Server 2016. Microsoft's extended support for Windows Server 2016 ends on 12 January 2027. After that, the operating system stops getting routine security updates under the standard lifecycle, and the framework support that rides on it goes with it.
So the first step is an inventory. List every server that runs a .NET Framework application, note its Windows version, and look up that version on Microsoft's lifecycle pages. The earliest date on that list is your real deadline. Moving the application to a newer Windows Server keeps the framework supported. You don't have to rewrite anything to stay inside the policy.
So why is everyone talking about migrating?
Because supported isn't the same as moving forward.
When Microsoft announced .NET 5 in May 2019, it said .NET Framework 4.8 would be the last major version of .NET Framework. Since then, new language features, performance work and most new libraries have gone to modern .NET. .NET Framework runs only on Windows. Modern .NET runs on Windows, Linux and macOS, and in containers.
None of that breaks a working application. It does mean the gap widens every year. Libraries stop shipping versions for the old framework, newer developers have less experience with it, and anything you'd like to run on Linux or in containers has to wait. For an application that rarely changes, that may be fine. For one the business keeps asking to change, it's a cost that builds slowly.
If you migrate, don't aim at .NET 8
This is the detail that catches teams out. A lot of migration guides, and a lot of searches, are about moving from .NET Framework to .NET 8. But according to Microsoft's .NET support policy, .NET 8 support ends on 10 November 2026, the same day as .NET 9.
The current long-term support release is .NET 10, released on 11 November 2025 and supported until 14 November 2028. A migration that starts now should target .NET 10. Otherwise you finish one migration and immediately owe another.
What doesn't move across as it is
Most class-library code ports without much drama. These parts need real decisions:
- WCF services. Modern .NET doesn't include the WCF server. The usual routes are CoreWCF, an open-source port of WCF that has had Microsoft product support since its 1.0 release in April 2022, or rewriting the service as REST or gRPC. Calling WCF services as a client is supported in modern .NET.
- ASP.NET Web Forms. There's no Web Forms in modern .NET. Those pages have to be rebuilt in something else, such as Razor Pages, MVC or Blazor. That's usually the biggest single item in the estimate.
- .NET Remoting and AppDomains. Neither is supported in modern .NET, so code that relies on them needs redesigning.
- Third-party packages. Some libraries never shipped a modern .NET version. Each one is either a replacement or a fork.
Analysis tools can flag APIs that won't port. What they can't tell you is which parts of the application the business still depends on, and which parts could simply be switched off. That's worth knowing before you estimate anything.
Stay, move the server, or migrate in pieces
For most .NET Framework estates, the decision lands in one of three places.
If the application is stable, changes rarely and runs on a Windows version with years of support left, staying on 4.8 is a legitimate choice. Write the Windows date down and revisit it.
If the Windows version is the problem, move the application to a newer Windows Server. It keeps you inside Microsoft's policy without changing the code.
If the application is under active development, migrate it in pieces. Move one service or module at a time to .NET 10 while the rest keeps running, which is the strangler fig approach we described in before you rewrite a legacy system.
Where the 30-day assessment fits
The 30-day assessment tells you which of those three applies to each application, and what a migration would really involve. It's fixed in scope, at a price agreed before we start. Over 30 days we go through the codebase and architecture, map how the system fits together, find the hidden architectural debt, and flag the security and compliance gaps, including the WCF, Web Forms and dependency issues that decide the size of a migration.
The report says in plain language what is broken and what it would take to fix it. Your team can act on it, or we can do the upgrade as a separate project with its own scope and price.