Rewriting vs. Migrating a WebForms Application to .NET 8

WebForms does not run on .NET Core or .NET 8, and that is a permanent architectural decision rather than a gap awaiting a future release. Applications that need to move forward have two paths: rewrite the application, or port the business logic to modern .NET and rebuild the UI layer.

The determining variable is how tightly the business logic is coupled to the WebForms layer. That property is not observable from outside the code, which is why estimates produced without reading it are unreliable in both directions.

What migration means here

Migration means extracting business logic and data access, porting it to .NET 8, and rebuilding the presentation layer in ASP.NET Core MVC, Razor Pages, or Blazor.

The entire WebForms surface is replaced: .aspx markup, code-behind, server controls, ViewState, and the PostBack model. None of these have equivalents. The logic underneath, where it is cleanly separated, can frequently be ported at substantially lower cost than reimplementation.

Where the logic sits in code-behind and depends on WebForms-specific APIs, the migration path and the rewrite path converge on the same amount of work. The label changes; the scope does not.

Assessing coupling

Coupling is measurable, and the measurement is what the decision should rest on.

Indicators that logic is extractable:

• Business rules live in separate class library projects with no System.Web reference
• Data access is in its own layer rather than in page code-behind
• Code-behind files are small and consist mainly of control wiring
• Domain types do not carry UI concerns

Indicators that logic is entangled:

• Business rules implemented directly in Page_Load and event handlers
• ViewState or Session used as working storage for business state rather than for UI state
• Database calls issued directly from page code-behind
• Domain logic that reads or writes control properties
• Validation implemented only through WebForms validator controls
• Business decisions driven by IsPostBack checks

The count of business rules in the second category against the first is the estimate.

Conditions favoring migration

Business logic is separated from the UI. Class libraries holding domain models, services, and data access frequently port with moderate effort. Where that separation exists, the project is rebuilding the web layer over already-ported logic, a contained scope with a testable intermediate state.

The application is large and the rules are complex. Rewriting a large system means reproducing years of accumulated behavior from documentation, user recollection, and observation of the existing system. Edge cases that took years to surface in production have to be found again. Porting existing, exercised logic carries materially less risk than reimplementing it.

Incremental delivery is required. A migration can be staged behind a routing layer, moving the highest-traffic or most actively developed pages first while lower-priority areas remain on the old platform. This requires running both applications concurrently with shared authentication, which is solvable and needs to be designed rather than assumed. A rewrite is generally an all-or-nothing cutover.

Conditions favoring a rewrite

Business logic is inseparable from the WebForms layer. If extraction requires rewriting the logic anyway, the migration path offers no advantage over a clean implementation against current requirements.

The existing design decisions need to change. Migration carries forward the data model and architecture. Where those are the problem (a schema that no longer fits the business, an architecture that blocks planned capability), the rewrite is the mechanism for changing them, and doing so during a migration is more expensive than doing it deliberately.

Requirements have materially diverged. A different user model, different data architecture, or different integration patterns mean the ported code was built for a different problem. Migrating it produces code that must then be substantially reworked.

The assessment that precedes the decision

One to two weeks of structured code review produces the inputs the decision requires. It is the least expensive part of either path.

Outputs to require:

• Extractable logic volume, expressed as the proportion of business rules in separable code versus in code-behind
• Dependency inventory. Packages without modern equivalents, System.Web usage, System.Drawing, COM interop, and any WCF hosting
• Data access approach and whether it ports
• Existing test coverage, which determines how behavior is verified after the move
• Authentication implementation, frequently the most coupled component and often underestimated
• Estimates for both paths, built from the above rather than from a template

Committing to a migration on assumption consistently underestimates the work, because the coupling that makes migration expensive is not visible from the outside. Committing to a rewrite on assumption consistently underestimates the accumulated production behavior the original system encodes. Both errors are avoided by the same two weeks of reading the code.