Why Migrate Away from Web Forms
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.
Cricket analogy: A team retiring an aging fast bowler who can no longer bowl 140 kmph spells brings in a fresh pace attack rather than patching the old bowler's action, similar to retiring Web Forms' Page model for ASP.NET Core's pipeline.
Migration Strategies: Rewrite vs. Strangler Fig
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.
Cricket analogy: A team rebuilding for a World Cup cycle doesn't drop every experienced player at once, they blend in new talent series by series, similar to strangler-fig migration moving one section of a site at a time.
// Reverse proxy config sketch: route new sections to ASP.NET Core,
// leave legacy Web Forms handling everything else (web.config URL Rewrite)
<rewrite>
<rules>
<rule name="Route Marketing to Core App" stopProcessing="true">
<match url="^marketing/(.*)$" />
<action type="Rewrite" url="http://localhost:5000/marketing/{R:1}" />
</rule>
<!-- Everything else falls through to the existing Web Forms app -->
</rules>
</rewrite>Reusing Business Logic and Mapping Concepts
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.
Cricket analogy: A player moving from Test cricket to T20 keeps the same core batting technique but adapts shot selection to the format, similar to how business logic classes stay largely unchanged while the UI layer is rewritten for Razor Pages.
A pragmatic first migration step is extracting business logic that still lives in code-behind into plain C# classes with no System.Web dependency, even before starting the ASP.NET Core rewrite — this shrinks the actual UI-only surface area that needs porting and de-risks the whole project.
Common Migration Pitfalls
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.
Cricket analogy: A team switching from red-ball to white-ball cricket underestimates how much fielding strategy has to change, not just the kit, similar to underestimating how much UI-state handling changes beyond just syntax when leaving ViewState behind.
Automated Web Forms-to-Core migration tools should be treated as accelerators for boilerplate, not a substitute for redesigning stateful UI flows — teams that rely on them for a full conversion typically end up with subtly broken multi-step forms because implicit ViewState behavior has no automatic equivalent.
- Web Forms is not supported on ASP.NET Core; migration is closer to a UI rewrite than a mechanical port.
- .NET Framework 4.8 receives only security patches, motivating migration for long-term support and cross-platform hosting.
- The strangler fig pattern migrates one section of a site at a time behind a reverse proxy, avoiding a risky big-bang cutover.
- Business logic already separated from code-behind can often be reused directly in the new ASP.NET Core project.
- GridView, Master Pages, and User Controls map conceptually to Razor loops, Layouts, and partial views but require hand rewriting.
- ViewState-driven implicit UI state must be redesigned explicitly using TempData, session, or re-querying per request.
- Automated conversion tools typically handle only the easiest fraction of an application, leaving stateful flows as manual work.
Practice what you learned
1. Why is migrating from Web Forms to ASP.NET Core generally considered closer to a rewrite than a port?
2. What is the main advantage of the strangler fig migration pattern over a full rewrite?
3. Why can business logic classes from a Web Forms app often be reused in an ASP.NET Core project with little change?
4. What must replace ViewState's implicit state persistence when migrating a multi-step wizard to Razor Pages?
5. What is a realistic expectation for automated Web Forms-to-Core migration tools?
Was this page helpful?
You May Also Like
Web Forms Best Practices
Practical guidelines for writing maintainable, secure, and performant ASP.NET Web Forms applications, from ViewState discipline to layered code organization.
Common Web Forms Pitfalls
The recurring lifecycle, ViewState, and event-handling mistakes that trip up developers working with classic ASP.NET Web Forms.
Classic ASP.NET Quick Reference
A condensed reference for the Web Forms page lifecycle, common controls, directives, and web.config settings.
Related Reading
Related Study Notes in Microsoft Technologies
Browse all study notesWindows 10 / UWP Development Study Notes
.NET · 30 topics
Microsoft TechnologiesWindows Batch Scripting Study Notes
Batch · 30 topics
Microsoft TechnologiesMFC (Microsoft Foundation Classes) Study Notes
C++ · 30 topics
Microsoft TechnologiesSilverlight Study Notes
.NET · 30 topics
Microsoft TechnologiesXAML Study Notes
.NET · 30 topics
Microsoft TechnologiesWPF (Windows Presentation Foundation) Study Notes
.NET · 30 topics