Rewriting vs. Migrating a WebForms Application to .NET 8

WebForms doesn't run on .NET Core or .NET 8. That's not a gap being addressed in a future release — it's a deliberate architectural decision that won't change. If you have a WebForms application that needs to keep moving forward, you have two options: rewrite the application, or migrate the business logic to a new framework while replacing the UI layer.

Neither option is a simple upgrade. The right choice depends on the structure of your specific codebase.

What "migration" means in this context

Migration here means: extract the business logic and data access code, port it to .NET 8, and rebuild the UI layer in ASP.NET Core MVC, Razor Pages, or Blazor. The WebForms markup — .aspx files, code-behind, server controls, ViewState, PostBack — gets replaced entirely. The logic underneath it, if it's cleanly separated, can often be ported with substantially less work than starting from scratch.

The viability of this approach depends almost entirely on how well-structured the existing code is. If the business logic is embedded in code-behind files and tightly coupled to WebForms-specific APIs, the migration and the rewrite end up involving similar amounts of work. The label changes but the scope doesn't.

When migration makes more sense

The business logic is reasonably separated from the UI. Class libraries that contain core business logic — domain models, service classes, data access code — can often be ported to .NET 8 with moderate effort. If that separation exists, the migration focuses on rebuilding the web layer on top of already-ported logic. That's a more contained project than a full rewrite.

The application is large and the business rules are complex. Rewriting a large system from scratch means reproducing years of accumulated business logic from requirements documents, user knowledge, and the behavior of the existing system. Edge cases that took years to find and fix in the original will need to be found again. Porting existing, tested logic is lower risk than reimplementing it.

You need to deliver incrementally. A migration can sometimes be staged — rewriting the highest-traffic or most actively developed pages first while leaving lower-priority areas on the old platform temporarily. A rewrite is typically an all-or-nothing commitment.

When a rewrite makes more sense

The business logic is inseparable from the WebForms layer. If the code-behind files contain the business logic and extracting it would require rewriting it anyway, the migration path doesn't offer a meaningful advantage over a clean rewrite.

The application carries significant technical debt that needs to be addressed. A migration carries technical debt forward. If the existing data model, architecture, or core design decisions need to change, a rewrite is an opportunity to make those changes from a clean starting point.

The requirements for the new version are substantially different from what was originally built. If the new application needs to do significantly different things — different user model, different data architecture, different integration patterns — rewriting to those requirements is cleaner than migrating code that was built for a different problem.

What to do before committing to either

The decision requires knowing how coupled the business logic is to the WebForms layer. That's not something you can assess from the outside or estimate quickly — it requires reading the code.

A structured assessment of the existing codebase takes one to two weeks and produces a clear answer: how much business logic is extractable and portable, what the external dependencies look like, what the test coverage is, and what a realistic estimate looks like for both paths.

Organizations that skip this step and commit to a migration based on assumption consistently underestimate the work, because the coupling that makes migration hard isn't visible until you've read the code. Organizations that assume a rewrite will be straightforward consistently underestimate how much complexity the original system accumulated over years of production use.

The honest starting point is: look at the code, then decide.