ASP.NET Web Forms Migration: What’s Blocking You and How to Move Forward

If your company was around when ASP.NET Web Forms was cutting-edge, your systems are probably still running on it. After all, years of custom business logic are a substantial asset, even without test coverage or documentation. ASP.NET Web Forms migration can break that logic, cause downtime, and incur higher-than-expected costs.

As our experience with technology modernization can attest, however, there’s a cost to staying with Web Forms.

For one, Web Forms runs only on the legacy .NET Framework. It’s effectively in maintenance mode, as we mentioned in our .NET Framework migration guide. That means no feature updates, only reliability and security patches. Forget about modern libraries, tools, and cloud-native deployment, too.

Unfortunately, Web Forms are notoriously difficult to migrate. Tools like the official .NET Upgrade Assistant can’t directly port them to .NET Core.

Read on to discover:

• What usually blocks ASP.NET Web Forms migration
• What your options are for replacing Web Forms
• How to switch over without downtime

Why Web Forms Is a Special Case in .NET Migration (At Least for Now)

ASP.NET Web Forms is the technology that generates the HTML code for your app’s user interface on the server. This back-and-forth tightly couples backend and frontend but allows developers to manage UI elements using C# backend code.

Legacy Web Forms modernization can remove the need for this back-and-forth and eliminate the hidden costs of relying on .NET Framework. Yet, it’s harder than your typical .NET Framework migration. Here’s why:

• No official upgrade path. Microsoft has announced that “Web Forms support is coming soon” for the GitHub Copilot modernization agent. But for now, there’s no official tool for migration.
• Code-behind coupling. The code-behind page authoring method allows you to store server-side and presentation-layer code in two separate files. But they are generated at the time, meaning they’re tightly bound.
• Reliance on ViewState. Many applications use ViewState for state management, but modern frameworks have no direct equivalent for it. So, you’ll have to redesign the logic that involves ViewState.
• Page lifecycle dependency. In Web Forms, business logic is usually wired to the page lifecycle. That approach is also a relic from the past, with no equivalent in modern frameworks.
• App size. A single app can consist of dozens or even hundreds of pages. Refactoring each of them one by one equals months of work.

Your Web Forms Replacement Options and How to Choose One

Since there’s no direct equivalent for ASP.NET Web Forms in .NET Core, you have to replace it with an alternative. You can choose from three options: Blazor, Razor Pages, and JavaScript frameworks (React, Angular, Vue).

Blazor

Blazor is Microsoft’s frontend web framework that runs on HTML, CSS, and C#, and Microsoft actively promotes Blazor as the default path for Web Forms.

Pros:

• Closest alternative to Web Forms. It’s component-based and stateful, with event handlers, data binding, and support for server-side hosting.
• Powered by C#. You don’t have to bring new developers on board or write large JavaScript scripts.
• Part of the .NET Core ecosystem. Blazor seamlessly integrates with the rest of the official .NET stack.

Cons:

• Blazor is a relatively young technology, less mature than Angular or React.
• Blazor developers are few, compared to Angular or React (7% vs 18.2% and 44.7%, respectively).
• You still have to rewrite some code to migrate Web Forms to Blazor.

Good for:

• Internal tools (dashboards, admin portals)
• B2B platforms
• Line-of-business applications

Razor Pages

Razor Pages is essentially the equivalent of Server Pages in .NET Core. It’s a server-side, page-focused framework that generates HTML pages on the server side.

Pros:

• Conceptually close to Web Forms. Every page is one endpoint with multiple handlers.
• Reduced disruption risk. You can migrate Web Forms pages one by one.
• Part of the .NET Core ecosystem. It’s a safe bet for long-term support, stability, and maturity.
• Easier debugging and deployment. It has fewer moving parts compared to JavaScript frameworks.

Cons:

• You may have to rebuild the user interface without server controls.
• It struggles with complex UI patterns on its own: pages reload, which slows interactions.
• It’s harder to reuse UI components compared to Blazor or JavaScript frameworks.

Good for:

• Page-by-page migration
• Form-heavy, relatively static websites
• Admin or workflow apps with no real-time dashboards

React, Angular, or Vue

React, Angular, and Vue are three modern JavaScript frameworks for building web applications. Turning to JavaScript means rebuilding the frontend and connecting it to the backend via .NET Core APIs.

Pros:

• Robust ecosystems. JavaScript frameworks come with tons of UI libraries, testing tools, and robust mobile support.
• Fresh start. You can fully decouple the frontend from the backend and implement advanced UI patterns (e.g., real-time dashboards).
• Easy-to-hire talent. React is the second most popular framework among developers.

Cons:

• This approach effectively requires redesigning the architecture, creating APIs, and rebuilding state handling and validation flows.
• For a team used to working with C#-powered Web Forms, switching to a JavaScript frontend is a big shift.
• Rewriting simple CRUD (Create, Read, Update, and Delete) apps with a JavaScript framework would introduce unnecessary complexity.

Good for:

• Websites with highly interactive interfaces
• Real-time collaboration tools

Blazor vs Razor Pages vs JavaScript Frameworks: Your Snapshot

So, should you migrate Web Forms to Razor Pages, Blazor, or a JavaScript framework? Here’s a comparison table to guide you through the main decision-making considerations:

	Blazor	Razor Pages	React, Angular, Vue
UI interactivity	Medium/High	Low	High
Required skill set	C#, .NET	C#, .NET	JavaScript/TypeScript
Backend rearchitecturing	Mostly remains the same	Mostly remains the same	Taking place in parallel
App size	Small/Medium	Large (incremental migration is best)	Medium/Large

How to Migrate from Web Forms Incrementally, Without Downtime

A big bang replacement is rarely a good idea due to the risks involved. So, Microsoft recommends incremental migration using the Strangler Fig pattern and YARP, a .NET library that provides core proxy functionality. This approach allows applications to stay live during modernization and avoid compatibility issues.

Step 1: Audit Before Making Any Code Changes

Before you can replace ASP.NET Web Forms, you need to know what you’re dealing with. To that end, map all Web Forms pages and their code-behind dependencies. Pay close attention to each page’s:

• ViewState and server controls. You’ll need to replace them with a combination of HTML, Tag Helpers, and model binding in the modern .NET Core.
• HttpModules/Handlers. It’s replaced with middleware and endpoint routing.
• Session-heavy logic. It increases complexity and file size, so you should keep it to a minimum.
• Third-party dependencies. Many controls, like Telerik or DevExpress, have no direct equivalent in Blazor or Razor Pages.
• Criticality. Migrate business-critical modules first and low-traffic pages second.

Step 2: Decouple Business Logic

It’s probably taken you years to create business logic that handles edge cases and perfectly matches your operational workflows. So, razing it and rebuilding core functionality from scratch is a no-go.

Good news: you can isolate that logic from the legacy UI with minimal rewriting. To that end, developers create a shared library with zero System.Web references, while keeping refactoring mostly stylistic.

As a migration approach, decoupling business logic has several undeniable benefits:

• It enables incremental modernization without destabilizing critical workflows
• You can reuse code tested by years of production
• You don’t have to explain millions of lines of new code to developers
• It lowers migration risk by removing regression and knowledge loss risks

Step 3: Run the New Frontend in Parallel via YARP

The Strangler Fig pattern and YARP are the key to zero Web Forms migration downtime.

The Strangler Fig pattern is a technique for gradually replacing parts of the legacy system with new ones, with a facade (proxy) routing user requests to either new or legacy components. Users remain none the wiser to the migration.

YARP, in turn, is a .NET library that enables core proxy functionality. It’s the technical “how” of implementing the Strangler Fig pattern, built for this very scenario.

Step 4: Migrate Page by Page

Incremental migration reduces risk and ensures zero downtime. But which pages should you start with?

At Exoft, we prioritize high-traffic but lower-risk pages. Here’s what incremental Web Forms migration looks like in practice:

• Modernize one page
• Deploy it in parallel with the legacy system using YARP
• Validate it under real production traffic
• Rinse and repeat until you run out of pages

But be warned: No amount of testing, no matter how thorough, can reveal all the issues that may appear in production. That’s why it’s important to validate pages under real traffic before decommissioning their legacy versions.

Step 5: Decommission Web Forms

Gradually, the old frontend will become obsolete as each Web Forms page is validated and replaced. Once all pages are modernized, you can decommission the legacy Web Forms frontend as it no longer serves any purpose.

Unlike a big-bang migration, you don’t have to bite your nails as developers change everything at once. With incremental migration, the legacy system stays live, and the risk associated with every change is spread out, making it more manageable to address.

AI-Assisted Engineering for Web Forms Migration

Web Forms migration used to be exorbitantly expensive. Developers had to spend hours upon hours analyzing the undocumented modules and unraveling dependencies before they could even get to refactoring code.

But that’s in the past. Today, thanks to AI, developers can complete the same legacy modernization scope in half the time.

AI tools make migration more economically and operationally viable by:

• Accelerating the discovery. Developers don’t have to spend weeks manually reverse-engineering legacy code. AI can explain undocumented modules and expose dependencies with a single click.
• Improving test coverage. AI can generate test coverage suggestions, making regression testing and workflow coverage more scalable and accessible.
• Reducing migration risk. Developers can modernize in small iterations while preserving the validated business logic. AI helps identify safer starting points for refactoring and testing.

«Thanks to AI in general and Claude in particular, we can do our jobs faster. For example, virtually any modernization project involves undocumented modules written a lifetime ago, and no one can tell us how they work or why they’re needed. AI can summarize that code and even suggest how to change it safely — all in a fraction of the time.»

At Exoft, we’re no strangers to accelerating migration with AI-assisted tools. In legacy .NET modernization, we use AI (including Copilot’s Modernization agents) for:

• Code analysis
• Dependency mapping
• UI modernization
• Regression testing

Conclusion: Overcoming the Downtime Fear

Critical software like banking apps, healthcare portals, and ERP systems can’t afford downtime. So, if that’s the reason you’ve been putting off Web Forms migration, remember: you don’t have to replace the frontend all at once.

For example, a global fintech company turned to Exoft torn between this very concern and the pressing need to modernize its core platform. So, as we gradually migrated its Web Forms frontend to Angular, the company’s banking operations remained live across multiple European markets.

The result? Zero downtime, zero disruption, and 20+ microservices modernized.

That is to say: you can replace Web Forms without tearing down years of business logic. All you have to do is opt for incremental migration with minimal refactoring.