ASP.NET Web Forms support and migration

Desktop-style programming for the web

Web Forms was Microsoft’s first web framework for .NET, released in 2002. It let developers build web pages the way they built Windows desktop screens: drop controls onto a page, double-click a button and write the code that runs when it is clicked. Many internal business systems, customer portals and back-office tools were built this way, and plenty are still in daily use.

To make that model work in a browser, Web Forms hides a good deal. Each page carries its state in a hidden field called ViewState, and each click posts the whole form back to the server, which rebuilds the page and runs the event handlers in its code-behind file. Web Forms is still supported as part of .NET Framework 4.8, but it is not available on modern .NET.

What tends to go wrong

• ViewState grows. A page with large grids sends its entire state to the server and back on every click, and users experience that as a slow system.
• Logic lives in code-behind. Business rules, data access and screen handling are mixed together in event handlers, so a rule cannot be tested or reused without the page around it.
• The page lifecycle causes subtle bugs. Behaviour depends on the order of events such as Init, Load and PreRender, and on whether the request is a postback. A change in one handler can break another.
• UpdatePanels hide the cost. Partial-page updates are quick to add, but each one still runs the full page lifecycle on the server.
• Control suites age. Grids, editors and report viewers bought from third-party vendors years ago may no longer be updated, and older versions were written for the browsers of their day.
• It blocks the move to modern .NET. The rest of an application may convert with modest changes. The pages cannot.

Your options

Stay on Web Forms and maintain it. A reasonable choice for a stable application with few changes. It should target .NET Framework 4.8 and run on a supported version of Windows Server. Anything targeting an older version should at least be retargeted.

Migrate page by page. The usual choice for a system with years of life ahead. Pages are rebuilt in ASP.NET Core using MVC, Razor Pages or Blazor, and each one takes over the address of the page it replaces. Old and new run together until the last page has moved.

Replace the application. Worth considering only when the system no longer fits how the business works. A Web Forms application usually holds years of tested business rules, and a replacement has to rediscover every one of them.

How we approach a migration

The first job is separating logic from pages. Rules and data access buried in code-behind are moved into plain classes, with tests, in libraries that both .NET Framework and modern .NET can use. This is worth doing even if the migration stops there, because it makes the existing application easier to change.

Next, an ASP.NET Core application is placed in front of the Web Forms one. It receives every request, serves the pages it has taken over and passes everything else through to the old application. Sign-in is shared between the two, so users log in once and cannot tell which application produced a page.

Pages then move in groups that belong together, such as everything to do with orders, starting with the areas that change most. Third-party controls are replaced as their pages move. Each group goes live on its own and can be routed back to the old pages if something is wrong.

The wider move from .NET Framework to modern .NET usually runs alongside it, and a .NET upgrade assessment is a fixed-price way to find out what your application involves. For version dates, see the .NET end-of-support dates.