Support status · ASP.NET Web Forms
Is ASP.NET Web Forms still supported?
ASP.NET Web Forms is supported. There is also no version of it on modern .NET, and there never will be.
From version 4.5.2 onwards .NET Framework is defined as a component of the Windows operating system, so it inherits the lifecycle of the Windows it is installed on. On a supported Windows, .NET Framework 4.8 is supported, and so is your Web Forms application. Nobody is going to send you an end-of-support notice. What Microsoft did instead was decline to bring Web Forms forward: it does not exist on .NET Core or any release after it, and no migration tool can produce it. Every route off the framework is a rebuild, which is why there is no deadline and no plan.
- .NET Framework 4.8
- Supported as a Windows component
- Web Forms on modern .NET
- Does not exist
- .NET Framework 4.6.1 and earlier
- Out of support since 26 April 2022
- Published end-of-support date
- None
Source: Microsoft: .NET Framework support policy. Check it. We would rather you did.
- Microsoft's own policy, linked
- No email needed to read it
- We will not tell you it is dying
What that actually means
The position most estates are in
Supported means the ground will not move, not that you can
The runtime is stable and will keep being patched. Everything built in the last decade is on the other side of a line the framework cannot cross: the current libraries, the current auth patterns, Linux hosting, containers that are not enormous, and the tooling every new hire expects.
The absence of a deadline is the reason nothing happens
A dated end of support is a budget line. "Supported indefinitely, going nowhere" is not, so the work never competes successfully for funding until something else forces it, usually a Windows Server upgrade, an acquisition, or a customer's security review.
ViewState and the control suite are the actual migration
A page whose state lives in ViewState and whose grid came from a third-party control vendor has no behavioural specification anywhere. The postback lifecycle is doing work that nobody has written down, and it is the part that quotes always miss.
What we do about it
The work itself
What the pages actually do, separated from the lifecycle
Code-behind read at volume, with the business rules pulled out from the Page_Load and event-handler ceremony they are tangled in. Most of the code in a Web Forms application is not about your business at all, and not porting it is most of the saving.
The control inventory, before anyone estimates
Every third-party control, every inherited server control, every place ViewState is carrying state between requests. This is the part that decides the number, and it is knowable before a plan is written rather than after.
Behaviour pinned before anything moves
Characterisation tests driven through HTTP against the running application, which for Web Forms means capturing the postback behaviour that no unit test in the solution currently covers.
Replaced page by page, both versions live
IIS keeps serving the .aspx pages that have not moved while the replacement serves the ones that have, on the same hostname and the same session. Each page reverts on its own.
What decides the cost
The three things worth knowing before anyone quotes
- Control suite
- A Telerik or DevExpress grid with server-side paging, templating and events is usually the most expensive thing in a Web Forms page to reproduce faithfully.
- ViewState
- How much state crosses requests inside ViewState decides whether pages can move one at a time or only in groups.
- Code-behind depth
- Business logic inside event handlers has to be recovered before it can be moved. Logic already in a service layer moves almost for free.
The engagement
How the work runs
You tell us what you have
Roughly how many pages, which control suite, and what would hurt most if it went wrong.
We read the code
Control inventory, ViewState dependence, how much logic sits in code-behind versus a real layer, and how much is dead.
One page goes first
A real page, in production, behind the same URL, with the old application still serving everything else.
The rest follows in that order
Measured against the first page rather than estimated, sequenced so the pages that block your platform decisions leave first.
Questions
Frequently asked
Is ASP.NET Web Forms still supported?
Yes. .NET Framework 4.5.2 and later are defined as components of the Windows operating system and follow the lifecycle of the Windows release they are installed on, so on a supported Windows your Web Forms application is supported. Anyone telling you Web Forms is end of life is either confused or selling something. That is the true answer, and it is not the useful one.
What is the actual deadline then?
There is not one, and that is the problem. Work with a date gets funded; work without one gets deferred until an external event sets the date for you. In practice the date arrives as a Windows Server end of support, a customer security review, a due-diligence exercise, or a senior developer leaving.
Can we move Web Forms to .NET 8 or later?
Not as Web Forms. It was not brought forward to .NET Core and is not in any release since, and no upgrade assistant can produce it because the target does not exist. Whatever you do next is a rebuild of the presentation tier. That is worth knowing before you scope it as an upgrade, because it changes who needs to be in the room.
Is Blazor the intended replacement?
It is the closest thing Microsoft offers in spirit, with a component model, server-side state and C# in the browser tier, and for a team deep in C# with no appetite for JavaScript it is a reasonable destination. Razor Pages is the simpler answer for page-shaped applications. We build in TypeScript, which suits teams who want one language across both tiers and a hiring pool that is not narrowing. All three are rebuilds of the same size; pick on what you can staff in five years.
Are we failing compliance if it is supported?
Not on this. Under a scheme like Cyber Essentials, software that no longer receives vendor security updates is an automatic failure, and .NET Framework 4.8 on a supported Windows does receive them. What does fail is the rest of what tends to sit around one of these applications: .NET Framework 4.6.1 and earlier went out of support on 26 April 2022, and the Windows Server underneath has a real date. Check those before you relax.
Most of our logic is in the code-behind. Does that make this harder?
It makes it larger, not harder, and it is the normal case rather than a confession. The work is recovering the rules from the event handlers and writing them down before anything moves. Where a genuine service layer already exists, that step shrinks accordingly.
Have you migrated Web Forms specifically?
Our deepest delivery experience is ColdFusion. The shape is the same, a page-and-postback model with business rules inside the page lifecycle, and the method is about reading code you did not write and pinning behaviour before changing it. What we will not do is show you a Web Forms case study we do not have.
Talk to someone who would read the code
A name, an email, and three optional questions. What comes back is a reply from the engineer who would read the code, and it is either a conversation about replacing it or an honest reason why we are not the right people.
Other platforms