A surprising amount of the business world still runs on ASP.NET WebForms and older ASP.NET MVC applications targeting the .NET Framework. These systems were often built fifteen or twenty years ago, and they have a habit of quietly outlasting every prediction of their demise. They process orders, manage claims, run internal operations, and embody years of accumulated business rules, and they keep doing it reliably enough that replacing them never quite reaches the top of the priority list. The technology underneath them, however, has moved on. The framework is in long-term maintenance mode, the talent pool is shrinking, and the architectural assumptions baked into the postback model feel increasingly alien to developers raised on modern .NET.
When the pressure to modernize finally arrives, the instinct of many teams is to propose a clean rewrite. Tear it all down, rebuild it properly on ASP.NET Core, and emerge with a modern system free of the old compromises. It is an appealing vision, and it is also the single most reliable way to turn a manageable problem into a catastrophe. The teams that succeed at modernization almost never do it in one heroic leap. They do it incrementally, and understanding why is the difference between a project that ships and one that quietly consumes two years and is then cancelled.
Why Full Rewrites Are Riskier Than They Appear
The core problem with a rewrite is that a working legacy application knows things nobody else does. Over the years it has absorbed an enormous quantity of business logic, much of it undocumented and some of it understood by no living employee. Every strange branch in the code, every special case for a particular customer or edge condition, is usually there because something in the real world demanded it. That knowledge exists nowhere but in the code, and a rewrite is forced to rediscover all of it, usually by breaking things in production and finding out what the old system silently handled.
Undocumented dependencies compound the danger. A WebForms application of any age tends to be entangled with its environment in ways that are not obvious from reading the source: scheduled jobs that touch the same database, integrations triggered by particular page events, reports that depend on a quirk of how a control rendered. A rewrite that captures the visible behaviour but misses these hidden connections will appear to work in testing and fail in ways that are maddening to diagnose once it is live.
And while all of this is happening, the business does not stand still. Requirements change, the old system still needs maintenance, and the team finds itself supporting two applications at once, the legacy one in production and the half-finished replacement that is perpetually almost ready. The new system is judged not against the old system's messy reality but against an idealized memory of it, and it loses that comparison for a long time. Replacing a working system with an incomplete one is a trade most organizations regret, and the graveyard of failed rewrites is large enough to be worth taking seriously.
The Strangler Fig Pattern
The more dependable approach borrows its name from a plant. The strangler fig grows around a host tree, gradually extending its own structure until it can stand on its own and the original tree, long since enclosed, withers away unnoticed. Applied to software, the idea is to grow the new system around the edges of the old one, replacing functionality piece by piece while both run together, until little or nothing of the legacy application remains. There is never a single terrifying cutover; instead there is a long series of small, reversible steps, each of which leaves a working system behind.
In an ASP.NET context, the practical entry point is usually a reverse proxy placed in front of the existing application. A tool such as YARP, Microsoft's reverse proxy library built on ASP.NET Core, can sit at the front door and route requests either to the legacy application or to new ASP.NET Core endpoints, with the client none the wiser. Once that routing layer exists, you can begin redirecting individual paths to modern code as each one is rebuilt. A single reporting page, a particular API endpoint, or one self-contained feature can be carved off and served by the new system while everything else continues to flow to the old one.
The pattern is not free of friction. You have to maintain two stacks during the transition, the proxy adds a layer to reason about, and shared concerns such as authentication and session state need careful handling across the boundary. But these costs are spread out and visible, rather than concentrated into one enormous bet, and that is precisely the point.
Migrating WebForms Incrementally
Before any of the routing helps, there is foundational work to do inside the legacy application itself, and it is work worth doing whether or not a migration ever completes. The most valuable single step is to separate business logic from the user interface. In a typical WebForms application, critical logic lives in the code-behind, tangled up with the page lifecycle, ViewState, and control events. Logic trapped there cannot be tested in isolation, cannot be reused, and cannot be carried forward to a new front end.
The remedy is to extract that logic into plain classes, ideally in a separate class library that targets .NET Standard or a modern .NET version so it can eventually be shared by both the old and new applications. A button click handler that currently calculates pricing, validates input, and writes to the database should be reduced to a thin shell that calls into a PricingService living in a clean library:
csharp
protected void SaveOrder_Click(object sender, EventArgs e)
{
var request = BuildOrderRequest(); // map from controls
var result = _orderService.PlaceOrder(request);
ShowResult(result); // update the page
}Once the real work lives behind an interface like IOrderService, the code-behind shrinks to glue, the logic becomes testable, and that same service can later be called from an ASP.NET Core controller without modification. This refactoring quietly turns an untestable monolith into a body of reusable code, and it is the highest-leverage investment most teams can make. Good early candidates are features that are well bounded and read-heavy, such as a standalone report or a lookup screen, because they carry low risk and let the team build confidence before tackling the transactional core.
Extracting APIs Before Rebuilding Front Ends
A common mistake is to start modernization by rebuilding the user interface, because that is the part everyone can see. It is almost always the wrong order. The interface is the most volatile and most opinionated layer, and rebuilding it first means committing to UI decisions before the foundation beneath it is sound. The better sequence is to expose the extracted business logic through APIs first, and replace the front end later.
Once your logic lives in service classes, wrapping it in ASP.NET Core Web API endpoints is straightforward, and the payoff is substantial. APIs are far easier to test automatically than page interactions, they create a clean contract that both the legacy UI and any future UI can consume, and they let new development proceed against a modern surface even while the old pages remain. During the transition, the legacy WebForms pages can begin calling these new APIs themselves, so that the path to the database increasingly runs through modern, tested code even before a single page is replaced. The result is a hybrid architecture, neither fully old nor fully new, that is genuinely stable rather than merely transitional, and that can persist comfortably for as long as the migration takes.
Managing Technical Debt During Modernization
Modernization is, at bottom, an exercise in prioritization, because you can never do all of it at once and should not try. The discipline that matters is distinguishing the legacy components that genuinely hurt from the ones that are merely old. A creaky module that almost never changes and quietly does its job is rarely worth touching, however unfashionable its code. The components that deserve attention are the ones where change is frequent and painful, where bugs cluster, or where the aging technology has become an active liability for security or hiring.
The useful frame is business impact against engineering effort. A subsystem that changes constantly and is agonizing to modify offers a high return on modernization, because every future change becomes cheaper. A stable, low-traffic corner offers almost none. Mapping the application this way, honestly, replaces the seductive but ruinous instinct to rewrite everything with a targeted plan that spends effort where it actually pays back.
The same accumulation problem appears across virtually every mature digital platform. Whether it is a banking portal, an insurance management system, a major e-commerce operation, or an entertainment platform such as Casino Dicepalace, years of continuous development tend to produce deeply interconnected business logic, hidden dependencies, and operational assumptions that are difficult to identify until they break. In practice, that is precisely why incremental modernization consistently proves less risky than starting over from scratch.
As systems evolve, every new feature, integration, workaround, and business requirement leaves its mark on the codebase. Over time, those decisions form a layer of institutional knowledge that rarely exists in documentation. A complete rewrite assumes that this knowledge can be rediscovered and recreated accurately, but experience shows that many of the most important behaviours only become visible when they disappear. Incremental migration reduces that risk by allowing teams to preserve proven functionality while modernizing the parts of the system that create the greatest operational friction.
The goal is not to eliminate technical debt overnight. The goal is to make future development faster, safer, and more predictable. Teams that succeed in modernization programs are usually the ones that accept this reality early. Instead of chasing architectural perfection, they focus on removing the constraints that most directly affect delivery speed, maintainability, security, and long-term sustainability. Over time, those targeted improvements compound, transforming even very old applications without exposing the business to the enormous risks that accompany a full-scale rewrite.
Moving Toward ASP.NET Core
The destination for most of this work is ASP.NET Core, and Microsoft has invested in making the journey incremental rather than all-or-nothing. The System.Web adapters, for instance, allow ASP.NET Core code to interoperate with patterns from the old System.Web world during a migration, smoothing the transition for applications that lean heavily on legacy APIs. Combined with a YARP-based proxy, this supports a genuine side-by-side model in which the Framework application and the Core application run together, sharing traffic, while functionality migrates a slice at a time.
Two operational concerns deserve early attention. The first is authentication. Running two stacks means users must move between them without re-logging-in, which usually involves sharing authentication cookies across the boundary by aligning the data protection keys and cookie configuration between the Framework and Core applications, or moving to a token-based scheme that both can honour. Getting this right early prevents a great deal of pain later. The second is operations: a hybrid system needs unified monitoring, logging, and deployment so that you can see across both halves and ship changes to either without ceremony. Treating observability and deployment as first-class parts of the migration, rather than afterthoughts, is what keeps a long transition manageable rather than chaotic.
Modernization Is a Process, Not a Project
The most important shift in modernizing legacy ASP.NET is one of mindset. A project has a defined end; a process is ongoing, and modernization is far better understood as the latter. The teams that succeed are not the ones who attempt a dramatic transformation and unveil a finished new system on launch day. They are the ones who treat modernization as continuous improvement, steadily extracting logic, exposing APIs, routing slices to ASP.NET Core, and retiring legacy paths, while the business runs without interruption throughout.
Approached this way, modernization loses its terror. There is no launch day to dread, only a long accumulation of small, reversible improvements that gradually leave the system more modern, more testable, and easier to work with than it was before. Risk stays low because no single step is large enough to be dangerous, and business continuity is preserved because the application keeps working at every stage. The old code does not have to be discarded in a grand gesture; it can be quietly grown over, slice by slice, until one day you notice that very little of the original remains, and that the thing you feared was a rewrite turned out, all along, to be ordinary engineering done patiently.
