Palm LeavesCare & migration
Is ASP.NET Web Forms end of life? Your migration options
Summary: ASP.NET Web Forms is not end of life in the strict sense: it ships with .NET Framework 4.8, which Microsoft supports as part of Windows. But it will not come to modern .NET, so every Web Forms application eventually needs a plan to stay secure where it is, or to move.
Where Web Forms stands today
Web Forms is part of .NET Framework, the original Windows-only .NET. Microsoft continues to support .NET Framework 4.8 and 4.8.1 for the life of the Windows versions they run on, with security fixes but no new features.
Modern .NET (currently .NET 10, a long-term support release supported until November 2028) does not include Web Forms, and Microsoft has said it will not be ported. So Web Forms applications are secure if their servers are patched, but they are frozen in place.
What actually forces a decision
In practice the pressure rarely comes from Web Forms itself. It comes from the things around it:
- Windows Server versions leaving support: Windows Server 2016 leaves extended support on 12 January 2027.
- Third-party libraries and controls that have stopped supporting .NET Framework.
- Security reviews and penetration tests flagging the application or its dependencies.
- Hiring: fewer developers want to work on Web Forms, and those who do cost more.
- Business change: new features take far longer than they would on a modern stack.
Option 1: keep it secure where it is
If the application is stable, rarely changes and is due to be replaced within a few years, the right answer can be to leave it on Web Forms and keep it safe: a supported Windows Server, monthly patching, updated dependencies, a hardened IIS configuration and monitoring. This is the lowest-cost option in the short term, and it buys time to plan.
Option 2: migrate incrementally to modern .NET
For applications the business depends on and keeps changing, the usual answer is a section-by-section move to ASP.NET Core on .NET 10. Microsoft documents this incremental approach: a new ASP.NET Core application sits in front of the old one, handles the routes that have been migrated and passes the rest through, while adapters let both applications share session and authentication.
Each Web Forms page is rebuilt, typically as Razor Pages, MVC or Blazor, with business logic moved into shared libraries. Users keep the same address throughout and never face a big-bang cutover.
Option 3: rebuild on a different stack
Sometimes the application has drifted so far from what the business needs that a rebuild makes more sense, for example as a React front end with a .NET or Node.js API, or a move to a SaaS product that now does the job. This carries the most risk, because hidden business rules in the old system are easy to miss. If you choose it, document the old system’s behaviour thoroughly first.
How to choose
These questions usually point clearly to one option:
- How often does the application change? Rarely: option 1. Often: option 2 or 3.
- How long will the business need it? Under three years: option 1 may be enough.
- Does it still match how the business works? If not, option 3 deserves a look.
- What does it depend on? Windows-only components and WCF services add effort to options 2 and 3.
- Who maintains it? If one person holds all the knowledge, documenting it is urgent whatever you choose.
A sensible first step
Whatever you decide, start with an audit: every page, service and dependency, the Windows Server and IIS versions underneath, and the sections that change most. That inventory turns a vague worry into a dated plan, and tells you which option you can afford.
Key takeaways
- Web Forms is supported with .NET Framework 4.8, but it will never reach modern .NET.
- The real deadlines come from Windows Server, libraries, security reviews and hiring.
- Keep it secure if it rarely changes; migrate incrementally if it matters and keeps changing.
- Start with an audit of pages, services, dependencies and servers.