ASP.NET WebForms to modern .NET: what changes and what to watch
Published 22 October 2026 · dotNew Labs
ASP.NET WebForms only runs on .NET Framework. Modern .NET has no WebForms, so moving a WebForms app is a rebuild of the user interface, not a version bump. Done in the right order, it is very manageable. Here is what changes and where projects usually slip.
Incremental migration: the new app sits in front and hands unfinished pages to the old one, so users see a single site throughout.
What has no direct equivalent
WebForms
Modern .NET
.aspx pages, server controls, ViewState, postbacks
Razor Pages, MVC or Blazor. Pages are rewritten.
System.Web, HttpContext.Current
ASP.NET Core request pipeline and dependency injection
Global.asax, HTTP modules and handlers
Middleware
web.config app settings
appsettings.json, environment settings, a secrets store
ASP.NET Membership, Forms authentication
ASP.NET Core Identity or your single sign-on provider
WCF services the app calls or hosts
Clients still work. Hosted services move to CoreWCF, gRPC or a REST API.
Pick the new front end per app, not per fashion
Razor Pages: closest to the page-by-page feel of WebForms. A good default for forms-heavy line-of-business apps.
MVC: fits apps that already separate logic from pages, or that will grow an API.
Blazor: component model that feels familiar to WebForms developers, good for rich screens. Check hosting and team skills first.
Move in stages, not in one jump
Microsoft supports an incremental path: put the new ASP.NET Core app in front, send requests for pages you haven't moved yet to the old app (using a reverse proxy such as YARP), and move pages over in batches. Users see one site the whole time. Each batch can be tested and released on its own.
Where WebForms projects usually go wrong
Rules hidden in code-behind. Validation, rounding and permission checks sit inside button-click handlers. Write them down before rewriting, or they get lost.
Session and ViewState. Pages that keep a lot of state between postbacks need a deliberate new design.
Reports. Crystal Reports and old ReportViewer controls need their own plan: SSRS, a paginated report service, or rebuilt reports.
Logins. Old Membership password hashes need a migration plan so users aren't locked out on day one.
No tests. Most WebForms apps have none. Record how the old app behaves with real examples, then test the new one against it.
A sensible order
Inventory pages, reports, jobs, integrations and logins.
Write down the business rules, cited to the code, and confirm them with the people who use the app.
Move shared business logic into class libraries that both old and new apps can use.
Stand up the new app in front, and move one low-risk area first.
Test old against new for each batch, then switch it over.
Not sure where your apps stand?
We offer a free 20-minute scan of one app: what it runs on, what's risky, and the shortest safe path forward. You keep a short written summary whether or not you hire us.