ASP.NET WebForms Migration to Modern .NET

Who this is for: .NET teams maintaining ASP.NET WebForms line-of-business apps who need a credible path to modern .NET without discarding years of domain code.

ASP.NET WebForms was never ported to .NET Core or modern .NET, so migrating a WebForms app always involves a rewrite. Teams choose between Blazor, ASP.NET Core MVC, Razor Pages, or Uno Platform, and can migrate incrementally by running legacy and modern apps side by side behind YARP.

Why ASP.NET WebForms Cannot Upgrade in Place

ASP.NET WebForms ships with the .NET Framework as a Windows-only component. Microsoft made an explicit decision not to carry it forward. The framework is stable and supported on .NET Framework 4.8.1, but it receives only security updates and cannot take advantage of the cross-platform runtime, Span-based performance improvements, or WebAssembly.

That means any move to modern .NET involves rewriting the UI layer. The good news is that well-architected WebForms apps with an N-tier separation between UI, business logic, and data access can reuse most of the non-UI code. The UI rewrite is the unavoidable part, and the sections below describe your options and the incremental pattern that makes the rewrite survivable.

Four Migration Targets in 2026

Four modern .NET targets are realistic replacements for ASP.NET WebForms. Each has a distinct fit.

Blazor offers the closest conceptual match to WebForms. It is a component-based, stateful UI framework with event handlers, data binding, and a server-side hosting model that resembles the postback round-trip. Microsoft positions Blazor as the primary migration path. Blazor Server and Blazor WebAssembly cover interactive UI scenarios entirely in C#.

ASP.NET Core MVC is the best fit when your team is comfortable with clean HTML markup, controllers, and views. It rewards teams that want explicit separation of concerns and testable request pipelines. MVC is the most flexible target but also the largest mental shift from the WebForms server control model.

Razor Pages is the lightweight option for page-based apps. If your WebForms application is mostly forms over data with limited shared state, Razor Pages maps neatly to the one-page-per-route model and avoids the controller layer.

Uno Platform is the right choice when your line-of-business roadmap extends beyond the browser. Uno Platform is an open-source .NET UI framework that reproduces the WinUI API surface and lets you build a single C# and XAML codebase that runs on web via WebAssembly, Windows, macOS, Linux, iOS, and Android. For LOB teams that have been asked to deliver a desktop companion, a field mobile app, or an offline client alongside the web UI, Uno Platform collapses four rewrites into one.

When Each Target Isn't the Right Fit

• Blazor: Wrong choice when your team already needs a native desktop or mobile companion and does not want to maintain two stacks.
• MVC: Wrong choice when developers want a component model that feels like WebForms.
• Razor Pages: Wrong choice when the app has heavy cross-page state or complex interactivity.
• Uno Platform: Wrong choice when the app is a pure, stateless website and the team wants the smallest possible rewrite.

Incremental Migration with YARP and System.Web Adapters

The safest way to migrate a large WebForms app is the Strangler Fig pattern: run the legacy and modern apps side by side and replace pages one at a time. The key pieces are YARP as the reverse proxy and System.Web Adapters to share session and authentication state between the old and new apps.

A minimal Program.cs for the modern .NET side:

using Microsoft.AspNetCore.SystemWebAdapters;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddSystemWebAdapters()
    .AddJsonSessionSerializer(options =>
    {
        options.RegisterKey<int>("UserId");
        options.RegisterKey<string>("TenantCode");
    })
    .AddRemoteAppClient(options =>
    {
        options.RemoteAppUrl = new Uri(builder.Configuration["LegacyAppUrl"]!);
        options.ApiKey = builder.Configuration["RemoteAppApiKey"]!;
    })
    .AddSessionClient()
    .AddAuthenticationClient(isDefaultScheme: true);

builder.Services.AddReverseProxy()
    .LoadFromConfig(builder.Configuration.GetSection("ReverseProxy"));

var app = builder.Build();

app.UseSystemWebAdapters();
app.MapReverseProxy();
app.MapRazorPages();

app.Run();

The legacy WebForms app installs the matching System.Web Adapters framework package and exposes a session endpoint. YARP routes every path that has not been migrated back to the WebForms app while new Razor Pages, Blazor components, or Uno Platform WebAssembly endpoints handle the migrated routes. The remote app session option is the right one when both apps must read the same session data during cutover.

Reusing Your Data Access and Business Logic

UI rewrites are expensive. Data access and business logic rewrites do not have to be. Extract your DAL and BLL into a .NET Standard 2.0 class library that both the legacy WebForms project and the modern .NET project can reference.

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
    <RootNamespace>Contoso.Lob.Core</RootNamespace>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.EntityFrameworkCore" Version="9.0.0" />
    <PackageReference Include="Microsoft.Windows.Compatibility" Version="9.0.0" />
  </ItemGroup>
</Project>

Entity Framework 6 can stay in the legacy project during cutover, but the modern project should target EF Core to take advantage of new providers and performance work. Any code that touches System.Web.HttpContext needs to be abstracted behind an interface before it moves into the shared library. For Windows-only APIs such as the Registry, WMI, or the Event Log, reference the Windows Compatibility Pack, which restores roughly 20,000 .NET Framework APIs on modern .NET.

The goal is a clean library with zero references to System.Web so it can compile against both runtimes. Once that library exists, the UI rewrite becomes an exercise in binding new views to code you already trust.

WebForms Features with No Direct Replacement

Some WebForms concepts do not translate one to one. Plan for these during the rewrite.

• ViewState. WebForms tracked control state in a hidden form field across postbacks. Modern frameworks track state explicitly in component fields, query parameters, or session. Budget time to decide where each piece of state belongs.
• Postback lifecycle and Page_Load. The Init, Load, PreRender, Unload event sequence is gone. Blazor components have their own lifecycle methods. Razor Pages and MVC use handler methods and action results instead.
• Server control tree. Controls like <asp:GridView> and <asp:Repeater> do not exist. Replace them with HTML plus Razor or XAML, or with a component library.
• Dynamic control creation. Code that adds controls to a tree on the fly must move to a component model that renders from data.
• DataSource controls. SqlDataSource and ObjectDataSource are not available. Call your services directly or use dependency injection to inject a repository.
• App_Code and dynamic compilation. Shared code moves to standard class libraries and compiles with the rest of the project.

Choosing Blazor, MVC, Razor Pages, or Uno Platform

If your roadmap is purely web and your team wants the shortest rewrite, choose Blazor or Razor Pages. If you need clean testable HTTP pipelines, choose MVC. If your line-of-business plans include any platform beyond the browser, give Uno Platform Studio a serious evaluation alongside the Microsoft options.

FAQ

Is ASP.NET WebForms still supported in 2026?

Yes. WebForms ships with .NET Framework 4.8.1 and receives security updates as part of Windows. It does not receive new features and is not available on modern .NET, so it is stable for maintenance but not for long-term investment.

How long does a WebForms to modern .NET migration take?

Small apps can migrate in two to four months. Medium and large LOB apps typically take six to eighteen months, depending on page count, custom controls, and how tightly the data layer is coupled to System.Web. Incremental migration with YARP reduces risk by letting you ship value every sprint.

Can I use Uno Platform to migrate a WebForms app?

Yes. The pivot is larger because you move from HTML and server controls to C# and XAML, but the payoff is a single codebase for every surface your users run on. You can host the resulting WebAssembly app on Azure Static Web Apps or any static host.

Do I have to rewrite my data access layer?

Not usually. If your DAL is already isolated from WebForms types, you can move it to a .NET Standard 2.0 class library and reference it from both the legacy and modern apps. Code that depends on HttpContext.Current or other System.Web types needs to be abstracted first.

Next Steps

ASP.NET WebForms modernization is a rewrite, but it does not have to be a rewrite of everything. Extract your business logic into a shared library, stand up the incremental pattern with YARP and System.Web Adapters, and pick the migration target that matches your roadmap. Blazor, MVC, and Razor Pages are safe web choices. Uno Platform is the right call when your line-of-business future extends beyond the browser.