Web Forms end of life is a date that doesn't exist. ASP.NET Web Forms ships as part of .NET Framework 4.8, and Microsoft supports .NET Framework 4.8 and 4.8.1 for as long as the Windows version they're installed on is supported. Your Web Forms application is supported today if its Windows Server is.
Supported isn't the same as going somewhere. Microsoft has said plainly that Web Forms won't be ported to modern .NET, so the real question is how much longer you want to build new features on a framework with no next version. This post covers what Microsoft says, the dates that apply, and the three ways forward.
- ASP.NET Web Forms has no end-of-life date of its own. It ships with .NET Framework, which follows the Windows lifecycle.
- Microsoft's Web Forms guide says it stays supported "as long as the .NET Framework ships as part of Windows."
- The real limit: Microsoft won't port Web Forms to modern .NET, so it can't move to ASP.NET Core, Linux or containers.
- For large apps, Microsoft recommends incremental migration: a new ASP.NET Core app in front, moving routes one at a time.
Is there a Web Forms end of life date?
- Microsoft doesn't publish one, because Web Forms isn't a separate product. The ASP.NET support policy says "Many parts of ASP.NET are a part of the Microsoft .NET Framework, these include ASP.NET Web Forms, Controls, Modules, Handlers, and more," and points to the .NET Framework policy for dates.
The .NET Framework support policy defines version 4.5.2 and later as "a component of the Windows operating system," and says: "As long as it is installed on a supported version of Windows, .NET Framework 4.8.1 will continue to also be supported." We cover that policy in .NET Framework 4.8 end of support.
Microsoft's guide Blazor for ASP.NET Web Forms developers is direct: "As long as the .NET Framework ships as part of Windows, ASP.NET Web Forms will be a supported framework." So any Microsoft Web Forms end of life question is really a Windows Server question.
The date that applies: your Windows Server
| Windows Server version | Extended support ends |
|---|---|
| Windows Server 2016 | 12 January 2027 |
| Windows Server 2019 | 9 January 2029 |
| Windows Server 2022 | 14 October 2031 |
Checked 27 October 2026 against Microsoft's lifecycle pages for Windows Server 2016, products ending in 2029 and Windows Server 2022.
Windows Server 2016 is the one to watch: its extended support ends in under three months. Moving a Web Forms app to a newer Windows Server keeps it inside Microsoft's policy without changing the code. What an unsupported server exposes you to is covered in the risks of running end-of-life software.
Why .NET Web Forms is still a dead end
Because it can't move forward. In May 2019, Microsoft's post .NET Core is the future of .NET said .NET Framework 4.8 "will be the last major version of .NET Framework," and told Web Forms developers building a new application on .NET Core: "we would recommend Blazor." The Blazor guide adds that "ASP.NET Web Forms won't be ported to .NET Core or .NET 8," and that Web Forms "ships with the .NET Framework as a Windows-only component, which means ASP.NET Web Forms apps can only run on Windows Server machines."
In practice that means:
- no Linux hosting and no Linux containers;
- none of the new features that ship with ASP.NET Core;
- new library releases that may no longer target .NET Framework;
- every feature you add to a Web Forms app now is a feature someone will later have to move.
For an app that rarely changes, that may be fine for years. For one the business keeps asking to change, the cost grows quietly. Web Forms apps turn up on most lists of legacy system examples for exactly this reason.
ASP.NET Web Forms migration: the three paths
| Option | What changes | When it fits | Main risk |
|---|---|---|---|
| Stay on .NET Framework 4.8 | No code changes; keep Windows Server current | Stable app, few changes | New work adds to what must move later |
| Incremental migration to ASP.NET Core | New app in front; pages move route by route to Razor Pages, MVC or Blazor | Large app that must stay in production | Two apps side by side, sharing sign-in and session |
| Rewrite | New application, often a new UI | Small app, or a process the business wants to change | Rules buried in code-behind and page events get lost |
What incremental migration looks like
Microsoft's guide to migrating ASP.NET Framework to ASP.NET Core is candid that this "is non-trivial for the majority of production apps." It recommends incremental migration for large applications and calls it "an implementation of the Strangler Fig pattern": the new application grows around the old one until nothing is left to replace.
The getting started page sets out the mechanics:
- Create a new ASP.NET Core project next to the Web Forms app, and use YARP, Microsoft's reverse proxy, to pass requests the new app doesn't handle yet to the old one.
- Move pages one route at a time. Only the class libraries those routes need have to be upgraded first.
- Use the System.Web adapters (the Microsoft.AspNetCore.SystemWebAdapters package) so shared libraries that use HttpContext run on both frameworks.
- Share sign-in through the adapters' remote authentication, and plan for session state, whose APIs Microsoft says are "much different" between the two.
Microsoft's upgrade tooling page now points to the GitHub Copilot app modernization extension for MVC, Web API and Web Forms projects. Our guide to migrating .NET Framework to .NET 10 covers the wider steps, and if the app also hosts services, see WCF in .NET Core.
Migrate ASP.NET Web Forms to MVC, Razor Pages or Blazor?
Each one rebuilds the page layer; none converts it. Blazor is the target Microsoft points Web Forms developers toward, because, in the Blazor guide's words, both frameworks "offer component-based, event-driven, stateful UI programming models." MVC and Razor Pages are the other two. Choose on your team's skills and the shape of the pages, not on which looks closest on paper.
Before you choose a path
The right path depends on what's inside the app: how much logic sits in code-behind and page events, how far System.Web reaches into shared libraries, and what relies on session state. The 30-day assessment is fixed in scope, at a price agreed before we start. Over 30 days we read the Web Forms codebase and the architecture around it, map how the pages, libraries, databases and services fit together, find the hidden architectural debt, and flag the security and compliance gaps, including servers near or past their Windows support date.
The report says in plain language what is broken and what it would take to fix it, and which path suits each part of the app. Your own team can act on it, or we can do the migration as a separate project with its own scope and price. Either way, the report stands on its own.
Ask us whether it's worth assessing before you commit to a migration path.