Migrating ASP.NET Web Forms to Modern .NET

If a .NET Framework migration has a single hardest part, it is usually the Web Forms. Part 2 sorted the estate into “ports cleanly” and “must be rebuilt”; Web Forms is the headline entry in the second column, and it is worth a part of its own because the difficulty is not where teams expect it to be.

ASP.NET Web Forms — the .aspx page model with its server controls, runat="server", view state, and rich page lifecycle — is a Framework-only technology with no equivalent on modern .NET. It was never ported to ASP.NET Core and never will be. There is no compatibility shim and no automated converter, because the things Web Forms is built on (the postback lifecycle, server-side control trees, view state) simply do not exist on the modern platform. So the only path is to rebuild.

That sounds like bad news, and the UI part of it genuinely is more work than a port. But the rebuild is also an opportunity to fix the thing that made Web Forms a maintenance problem in the first place — and the real difficulty turns out to be somewhere other than the screens.

Where the difficulty actually lives

The instinct is to size a Web Forms migration by counting pages and imagining redrawing each one. That undercounts the hard part badly.

Web Forms actively encouraged putting business logic in the page code-behind — in Page_Load, in button-click handlers, woven through the lifecycle events and leaning on view state to carry data between postbacks. Over years, that is where the rules accumulated: the validation nobody documented, the special case for one customer type, the calculation that has to run in exactly this order. The page is not just a UI; it is a UI with the business logic fused into it.

Migrating Web Forms is not a UI project — it is a logic-recovery project wearing a UI costume. Redrawing the screen on a modern stack is the visible, mechanical part. Finding every rule buried in the code-behind and re-homing it without losing behavior is the part that decides whether the migration succeeds.

Choosing the modern target

Before the page-by-page work, pick where the pages are going. Modern .NET offers three realistic destinations:

• Blazor is usually the most natural target. Its component-and-event model is the closest thing modern .NET has to the Web Forms experience — reusable components, server-side event handling — so the team’s mental model carries over with the least friction. For a Web Forms shop, this is often the gentlest landing.
• Razor Pages suits simpler, page-centric applications. It is lightweight, page-focused, and easy to reason about, without the ceremony of a full MVC structure.
• MVC gives the most control and the cleanest separation, and is a strong choice when you also want to expose a proper API alongside the UI.

There is no universally correct answer; the choice depends on the application’s complexity and the team’s appetite. What matters more than the destination is that the method is identical whichever you pick.

The page-by-page method

The migration runs on the same incremental loop as the rest of the platform move, applied to one page (or a small cluster of related pages) at a time, behind the facade from Part 2.

1. Extract the logic first. Before rebuilding any UI, lift the business logic out of the code-behind into a plain class library — the multi-targeted shared library from Part 2 wherever possible. This is the single most important step. It separates “what the page does” from “how the page looks,” lets the logic be unit-tested in isolation, and means the rebuilt UI calls into proven code rather than re-implementing it. It also happens to leave the old Web Forms page working against the same extracted logic during the transition.
2. Rebuild the page on the chosen stack (Blazor/Razor Pages/MVC), calling into the extracted logic. The new page is a thin presentation layer over a clean library — the opposite of the fused model you started with.
3. Prove parity. Drive the rebuilt page with the same inputs as the original and confirm it produces the same outputs, the same data effects, and the same handling of the awkward edge cases. Equivalence is demonstrated, not assumed — and the awkward edge cases are exactly the undocumented rules you just extracted, so this step is also where you find out whether the extraction was complete.
4. Cut over behind the facade. Route that page’s URL to the new implementation. If something is wrong, the route flips back. Once stable, retire the .aspx version.

Repeat per page. Shared concerns — master pages become layouts, authentication moves to the modern middleware model, server controls become components or tag helpers — are solved once and reused across pages.

The patterns that need a deliberate answer

A handful of Web Forms mechanisms have no direct modern equivalent, and deciding how to handle each one before you start saves a lot of mid-migration thrashing:

• View state. Web Forms quietly round-tripped control state through a hidden field on every postback. Modern stacks have no such thing, and code that relied on it is relying on an implementation detail. The migration replaces it with explicit state — component state in Blazor, model binding in Razor Pages/MVC — which usually makes the data flow clearer than it was.
• The page lifecycle. Page_Init, Page_Load, PreRender, and the event ordering between them are Web Forms concepts. Logic that depended on when in the lifecycle it ran has to be re-expressed in the new model’s much simpler flow. Untangling lifecycle-dependent code is part of the logic extraction, not an afterthought.
• Server controls and third-party control suites. Heavy reliance on a commercial Web Forms control suite (grids, schedulers) is a real cost item, because those controls have no modern equivalent and their behavior must be reproduced or replaced with a modern component library. Inventory these early; they often drive the timeline more than the page count does.

Naming these up front turns “Web Forms is hard” into a concrete checklist, which is what makes the rebuild estimable instead of open-ended.

What makes this safer than it sounds

A Web Forms rebuild has a reputation for being a rewrite by another name, and it would be if you tried to do all the pages at once. The incremental version is different in kind: at every moment, most of the app is still the running Web Forms application, and only the pages you have proven are on the new stack. There is no flag day. A rebuilt page that misbehaves is one route flip away from reverting, not a production incident.

This matters because the alternative — freeze the app, rebuild the whole UI, cut over on a date — is the exact big-bang shape that fails most often. The logic-extraction step is also what de-risks it: once the rules live in a tested library, the UI in front of them can change without the rules changing underneath, which is the whole point.

Triage the pages honestly

Some Web Forms pages are genuinely thin — a grid bound to a query, a form that calls a stored procedure — with almost no logic in the code-behind. Those rebuild quickly and need little parity ceremony beyond a visual check. The heavy method described here is aimed at the pages that earned their reputation: the ones where the code-behind is hundreds of lines of accumulated rules. Triage honestly, and spend the effort where the logic actually is. And if the app is small and entirely thin pages, the lighter “convert and ship” path from Part 2 may be all it needs.

Where this leads

Web Forms is the UI half of the “must be rebuilt” column. The service half is just as Framework-bound and just as common: the WCF and ASMX services that wire .NET systems to each other and to the outside world. Part 4, Migrating WCF and ASMX Services to Modern .NET, covers what replaces them — gRPC, REST, and CoreWCF — and how to move a service contract without breaking the callers that depend on it.