ASP.NET Web Forms Migration: Comparing Your Target Options

Why there is no in-place upgrade path

Web Forms does not exist in ASP.NET Core, and it never will. Microsoft did not port it when .NET Core was built, and the current migration documentation treats the user interface as something to be rewritten rather than upgraded.

This is not a tooling gap that better tooling will close. The Web Forms page model is built on concepts that modern ASP.NET Core has no equivalent for:

• Server controls with a server-side object model
• ViewState round-tripping control state through the page
• Postbacks and the page lifecycle events that hang off them
• The System.Web request pipeline, and HttpContext used pervasively through the code

Microsoft’s own migration guidance is blunt about the size of the problem. It lists System.Web dependency, session state, authentication models, and dependency injection as cross-cutting concerns that all have to be addressed, and concludes that “these challenges make incremental migration the preferred approach for most production applications”.

That conclusion is the useful part. Once you accept the interface is a rewrite, the question stops being “how do we migrate Web Forms” and becomes “what should the replacement be”.

What is actually worth keeping?

Most of the value in a mature Web Forms application is not in the pages. Sort the codebase into three buckets before choosing anything.

Keep and port. Business logic, domain services, data access, the database schema, integrations, scheduled jobs, and report generation. This is usually the majority of the code by volume and nearly all of it by value. Much of it will move to modern .NET with modest change.

Rewrite. Everything that encodes the page model: .aspx and .ascx markup, code-behind files, ViewState handling, server control usage, and any logic that reads or writes HttpContext directly from a business class.

Delete. Every estate of this age has screens nobody uses. Before you price a migration, instrument the live application and find out which pages are actually hit. It is common to find a meaningful fraction of a Web Forms application can simply be retired, and that is the cheapest modernisation available.

The sorting exercise is worth doing properly, because it changes the size of the project more than the choice of framework does.

The move that pays off whatever you choose

Extract the business logic into an ASP.NET Core API before you decide on the front end.

In a typical Web Forms application, business rules have leaked into code-behind over the years. Pulling them into a service layer and exposing them through an ASP.NET Core Web API does four things at once:

• It decouples the interface decision, so you can defer or change it without redoing the work
• It gives you an integration surface for partners and customers, which most estates need anyway
• It gives mobile applications and field devices something to talk to
• It makes the logic testable, which is usually where the automated regression suite starts

This is the durable asset. Front-end frameworks come and go on a five to seven year cycle. A well-designed API over your domain outlives all of them. If budget only stretches to one phase, make it this one.

It also means the eventual interface choice is reversible. A team that regrets picking Blazor can put React in front of the same API without touching the business logic.

Which target should you choose?

There are four credible destinations, plus the option of doing nothing. None is universally right, and most real estates end up using more than one.

Option one: stay on .NET Framework 4.8

Doing nothing to the interface is a legitimate choice for screens that are stable and rarely touched.

.NET Framework 4.8 and 4.8.1 are components of Windows, and Microsoft supports them “following the lifecycle policy of the underlying Windows OS on which it is installed”. There is no imminent support cliff, and security patches continue to arrive through Windows Update.

The pressure is strategic rather than urgent:

• No new framework features are coming, ever
• The recruitment pool for Web Forms shrinks every year, and the people who remain cost more
• Your application lifecycle is tied to Windows Server lifecycles
• Modern libraries increasingly target .NET, not .NET Framework

Choose this for screens that work, are rarely changed, and are not on the growth path. Do not choose this for anything you expect to invest in, because every year of investment in a Web Forms screen is written off at migration.

Option two: ASP.NET Core MVC or Razor Pages

Server-rendered pages on modern .NET. The lowest-complexity destination, and the most underrated.

There are no postbacks, no ViewState, and no server controls, so the page code is a rewrite. But the mental model, request in and HTML out, is close enough that experienced Web Forms developers pick it up quickly. Hosting is a single application, deployment is straightforward, and there is no JavaScript build pipeline to maintain.

Choose this for forms-heavy administrative screens, list and detail views, and reporting pages where a single-page application would be over-engineering. Do not choose this for screens that need rich client-side interactivity, offline behaviour, or a genuinely modern user experience.

Option three: Blazor

Blazor is the target Microsoft points Web Forms developers towards, and the comparison is fair. It uses reusable components and an event-driven model that maps recognisably onto how Web Forms developers already think, and it is C# from end to end.

The honest trade-offs:

• The recruitment pool is much smaller than for React, and salaries reflect scarcity in both directions
• Server-side rendering modes hold a live connection per user, which affects scaling and behaviour on unreliable networks
• The wider component and library ecosystem is thinner than the JavaScript ecosystem

Choose this for internal line-of-business applications maintained by a team you intend to keep C#-only, where the screens are forms and grids rather than rich interactions. Do not choose this for high-traffic public applications, or where you will need to hire front-end specialists from a general market.

Option four: React with a .NET API

This is the mainstream option, and for many estates it is the right one.

The architecture is a clean separation: ASP.NET Core Web API on the server, React on the client, talking over HTTP. It is the pattern most new systems are built to, which is precisely why it is easy to staff.

What it buys you:

• The largest recruitment pool of any option here, by a wide margin
• A component ecosystem that covers almost any interface requirement
• The same API serving web, mobile applications, field devices, and partner integrations
• A genuine user experience refresh rather than a re-skin of the same page flow

What it costs you:

• Two skill sets to maintain, or a team that spans both
• Authentication and session handling to design properly rather than inherit
• A JavaScript build pipeline, dependency updates, and the maintenance that comes with it
• More architectural decisions taken up front

Choose this for customer-facing or member-facing applications, anything where the user experience is a business objective, and estates that also need to serve mobile or partner integrations. Do not choose this for a small internal application with ten users and no user experience ambition, where it is more machinery than the problem deserves.

Do you need Next.js?

Usually not, for a line-of-business migration.

Next.js adds server-side rendering, file-based routing, and a Node server tier. Those pay off when first-load performance and search engine visibility matter, which mostly means public-facing pages.

For an internal application behind a login, none of that applies, and the Node tier is an extra thing to host, secure, and patch alongside your .NET application. A plain React single-page application built with Vite, served as static files from Azure Static Web Apps or blob storage, talking to your ASP.NET Core API, is simpler and cheaper to run.

Reach for Next.js when the public marketing surface and the application are the same codebase, or when search visibility is a requirement.

Option five: replace the screen entirely

Some Web Forms screens should not be migrated at all. They should be replaced with something you do not have to maintain.

Peripheral administrative screens, simple approval workflows, and internal request forms are often better served by a low-code tool or an off-the-shelf product than by any custom rewrite. The test is whether the screen encodes competitive advantage. If it does not, migrating it is spending build budget on a commodity.

Should you migrate incrementally or in one release?

Incrementally, for anything of meaningful size. Microsoft’s guidance points the same way: incremental migration for large production applications and applications that must stay live, in-place migration only for small ones.

The mechanism is the Strangler Fig pattern. A reverse proxy sits in front of both applications and routes each request to either the old Web Forms application or the new one. Screens move across individually. Shared session state and authentication are bridged so a user cannot tell which application served a given page.

Microsoft supports this directly with the System.Web adapters and YARP, its reverse proxy. The practical consequences are what matter:

• The system stays live throughout, with no big-bang cutover weekend
• Each screen is a small, reversible release rather than one enormous risk
• Value arrives during the migration instead of at the end of it
• The migration can pause when the business needs the team elsewhere, and resume later

The cost is running two applications side by side for the duration, and building the bridge for authentication and session. On a 6 to 7 million line estate, that cost is trivial next to the risk it removes.

Set the order deliberately. Move the screens with the highest business value or the worst user experience first, so the benefit is visible early and the appetite for the programme survives.

Which .NET version should you target?

Target .NET 10. It is the current Long Term Support release, published in November 2025 and supported until November 2028.

This matters more than it looks right now. .NET 8 and .NET 9 both leave support in November 2026. A migration that targets either is buying an upgrade before the migration has even finished.

How does AI-augmented development change the maths?

It changes the ratio between the two kinds of work in this project.

A Web Forms migration is part mechanical translation and part architectural judgement. Mechanical translation is exactly what AI coding tools are good at: porting data access, generating tests around existing behaviour, producing documentation from code, and translating repetitive page logic. Microsoft now ships a GitHub Copilot app modernization agent that assesses a solution and generates an upgrade plan.

Two consequences for planning:

• The characterisation tests that make a migration safe, historically the first thing cut for time, are now cheap enough to be non-negotiable
• The undocumented-system problem shrinks, because architecture maps and data flow documentation can be generated from the code itself

What does not change is the architectural judgement: which screens to retire, where the module boundaries fall, and what the API should look like. Those decisions still set the outcome, and getting them wrong is not something faster code generation rescues.

We publish measured delivery data quarterly in our AI Velocity Report.

How should you sequence the work?

A defensible order for a large Web Forms estate:

1. Instrument and measure. Find out which screens are actually used before pricing anything.
2. Assess the codebase. Sort it into keep, rewrite, and delete. Our legacy .NET assessment framework sets out how to score it.
3. Build characterisation tests around the behaviour you must not break.
4. Extract the business logic into an ASP.NET Core API. This is the durable asset.
5. Stand up the proxy and prove the routing and authentication bridge with one low-risk screen.
6. Migrate by business value, highest first, choosing the target per screen rather than globally.
7. Retire the Web Forms application when the last screen worth keeping has moved.

Steps one to four deliver value on their own. If the programme stalls after step four, you still have an API, a test suite, and a documented estate, which is a better position than you started in.

Related reading

• Modernising legacy .NET applications with AI covers the migration patterns in technical depth
• Legacy .NET assessment framework scores an estate before you commit
• Modernise, rebuild, or replace works through the strategic decision above this one
• .NET Development and Legacy Application Modernisation describe how we deliver this work

To talk through your own estate, book a consultation.