Migrating Web Forms to ASP.NET Core

Web Forms is not supported on modern ASP.NET Core, which runs cross-platform on .NET and drops the Page/control/ViewState model entirely in favor of Razor Pages, MVC, or Blazor. Organizations migrate for several concrete reasons: .NET Framework 4.8 is the last version and receives only security patches, cross-platform hosting on Linux containers is impossible with classic Web Forms, and the request pipeline's middleware model in ASP.NET Core is far more testable and composable than HttpModules and HttpHandlers. Migration is rarely a mechanical port — it is closer to a rewrite of the UI layer with the option to reuse business and data-access layers if they were already separated from the page classes.

Two dominant strategies exist. A full rewrite ports the entire application to ASP.NET Core MVC or Razor Pages in one project, which is cleanest for smaller applications but risky for large ones due to the scope of behavior that must be reproduced. The strangler fig pattern instead runs the legacy Web Forms app and a new ASP.NET Core app side by side behind a reverse proxy (such as IIS URL Rewrite or YARP), migrating one section of the site at a time — for example moving the public marketing pages to Razor Pages first while the complex order-management screens stay on Web Forms until later — so the business keeps shipping value throughout the migration instead of freezing feature work for a big-bang cutover.

If the Web Forms app already separated business logic and data access into plain classes (as recommended in Web Forms best practices), those classes can often be referenced directly from the new ASP.NET Core project with minimal change, since they don't depend on System.Web. The bigger rewrite is the UI layer: GridView becomes a Razor foreach loop or a component, Page_Load's initial-load logic becomes a Razor Page's OnGet handler, Button Click handlers become OnPost handlers or MVC action methods, and ViewState-based state persistence is replaced with TempData, session, or simply re-querying data on each request since Razor Pages has no automatic UI state persistence.

Teams frequently underestimate the effort of replacing implicit ViewState-driven UI state (like a multi-step wizard that relied on control values surviving postbacks automatically) and end up needing an explicit state design using TempData, session, or a client-side framework. Master Pages map conceptually to Razor Layouts but the syntax and directive model differ enough that they must be hand-rewritten rather than auto-converted, and User Controls (.ascx) map to Razor partial views or view components but with a different data-binding approach. Automated Web Forms-to-Core converter tools exist but typically handle only the easiest ~20-30% of a real application, leaving the event-driven, stateful parts as manual work.