ASP.NET Web Forms to ASP.NET Core Migration

ASP.NET Core does not include Web Forms. There is no compatibility shim, no project upgrade that keeps .aspx pages working, and no supported way to run the Web Forms page lifecycle on the new platform. The postback model, view state and the server control hierarchy simply do not exist there.

That means pages are rebuilt as MVC or Razor Pages rather than converted. It sounds worse than it is: the rebuild is mostly mechanical for simple screens, and the real work is extracting the business rules that sit in code-behind files so they can live somewhere testable.

This is the same extend-rather-replace discipline described on legacy ASP.NET modernization, applied to a platform gap rather than to a language change.

The Strangler Fig pattern grows the new application around the old one. New ASP.NET Core 8 code takes over one feature at a time, and the Web Forms application keeps serving everything that has not moved yet. There is no date when everything changes at once.

A YARP reverse proxy sits in front of both and routes each request to whichever application owns that path. To a user there is one site at one address, and they cannot tell which half answered. Handing a feature over becomes a routing decision you can reverse in a moment if something is wrong.

This is how we completed a Web Forms to ASP.NET Core 8 migration for a US consumer electronics brand, with the next phase now underway. That system has to keep taking orders throughout.

The tempting plan is to migrate by layer: all the data access, then all the logic, then the screens. It fails because nothing works until the last layer lands, so there is no point at which you can prove progress or stop safely.

A vertical slice takes one feature end to end, its screen, its rules and its queries, and moves the whole thing. When the slice is done it is genuinely done: it serves real users and can be verified against the old version of the same feature.

Slice order is a risk decision rather than an importance decision. Something with heavy traffic and simple rules exercises the proxy, the authentication and the deployment path properly while a mistake stays cheap.

Most Web Forms systems of any age have work running outside the web application: console applications on a schedule, batch processes, overnight imports and exports. They do not appear anywhere in the web project, which is why they are usually missing from the plan.

They need their own migration track, running in parallel with the web application rather than after it. They often share data access code with the web tier, so the order in which the two tracks move has to be agreed rather than discovered.

For anything that produces output another party depends on, such as documents going to a trading partner, the new code runs in shadow mode first. It generates the same documents alongside the old code, and the two outputs are compared.

Only once the new output matches does it take over as the real one. That turns a nervous cutover into a comparison you can run as many times as you like, and it catches the differences that only appear on real data rather than on test cases.

The same comparison discipline, applied to Classic ASP rather than Web Forms, is set out step by step in our Classic ASP to ASP.NET migration guide.

Before any slice moves, the dependencies decide what is possible. Check which packages have a version that runs on current .NET, which Windows-only components the application relies on, and which third-party libraries are still maintained at all.

Anything with no forward path is a decision rather than a blocker: wrap it and keep calling it for now, replace it, or let it hold a slice back while the rest proceeds. What matters is knowing which before planning the order, not discovering it halfway through a slice.

Where a dependency cannot move yet, that is an argument for landing on ASP.NET MVC on .NET Framework first rather than going straight to Core. Our .NET development work covers both targets.