Almost every organisation that has built software for any length of time owns a legacy .NET application that still earns its keep. It runs critical processes, embodies years of hard-won business rules, and quietly resists every attempt to improve it. The temptation, when the framework is outdated and the code has grown brittle, is to declare bankruptcy and rewrite the whole thing from scratch. It is also the temptation most likely to end in disaster. Understanding why, and what to do instead, is one of the most valuable skills a senior .NET developer can develop.
The Trouble with the Big-Bang Rewrite
The appeal of a complete rewrite is obvious. A clean slate promises modern frameworks, tidy architecture, and freedom from the accumulated compromises of the past. In reality, full rewrites are notorious for running over time and budget, and a striking number never ship at all. The reason is that a working legacy system, however ugly, encodes an enormous amount of knowledge. Every strange conditional and awkward special case is usually there because a real situation demanded it, and much of that reasoning lives nowhere but in the code itself. A rewrite has to rediscover all of it while simultaneously hitting a moving target, because the business does not stop changing its requirements to wait for the new system. Meanwhile the old application must be maintained in parallel, doubling the work. Many ambitious rewrites collapse under this weight.
The Strangler Fig Approach
The more reliable path is incremental, and the metaphor that best captures it is the strangler fig, a plant that grows around a host tree, gradually taking over until it can stand on its own and the original has quietly disappeared. Applied to software, the idea is to build the new system around the edges of the old one, replacing functionality piece by piece while both run side by side. New features are written in modern .NET, and existing features are migrated one at a time, until eventually little or nothing of the legacy code remains. At no point is there a single terrifying cut-over. The business keeps running throughout, and risk is spread across many small steps rather than concentrated in one enormous leap.
The first practical move is usually to place a routing layer in front of the application, often a reverse proxy or gateway, so that requests can be directed either to the legacy system or to its modern replacements without the caller knowing the difference. With this seam in place, you can begin redirecting individual routes to new code as each one is rebuilt, retiring the corresponding legacy paths only when the replacement is proven.
Finding the Seams
Incremental migration depends on being able to carve the monolith into pieces that can be replaced independently, and legacy code rarely makes this easy. The work of finding seams, the points where you can insert a boundary without unravelling everything, is the heart of the effort. A common technique is to introduce an interface in front of a tangled subsystem, then route calls through it. Once the rest of the code depends only on that abstraction, the implementation behind it can be swapped for a modern one:
csharp
// A seam introduced in front of legacy logic
public interface IPricingService
{
decimal CalculatePrice(Order order);
}
// The legacy implementation is wrapped, not yet replaced
public class LegacyPricingService : IPricingService
{
public decimal CalculatePrice(Order order) => LegacyPricing.Compute(order);
}With the seam established, a new implementation can be developed and tested in isolation, then introduced behind the same interface when ready. The surrounding code neither knows nor cares which version is running.
Guarding the Boundary
When old and new systems coexist, their models often disagree. The legacy database may use conventions and structures that you have no wish to carry into the new design. To prevent the old model from contaminating the new one, it is wise to place an anti-corruption layer between them, a translation boundary that converts between the legacy representation and the clean model on the modern side. This layer absorbs the messiness of the past so that new code can be written against sensible abstractions, and it can be discarded once the legacy system is finally gone. Without it, the very compromises you set out to escape tend to seep into the replacement, and the modernisation quietly defeats its own purpose.
Sequencing the Work
Deciding what to migrate first is as much a business question as a technical one. The most valuable early targets are usually the areas that change most often, since modernising them yields the greatest ongoing benefit, or the areas that pose the greatest risk, where the legacy technology has become a liability. Stable, rarely-touched corners of the system can often be left until last, or even left alone indefinitely, because there is little value in rewriting code that works and never changes. Each increment should deliver something real, leaving the application a little more modern and a little easier to work with than before, so that value flows continuously rather than arriving only at a distant finish line that may never come.
Modernisation handled this way is undramatic by design. There is no triumphant launch day, only a steady accumulation of small improvements that gradually transform the system from the inside. That lack of drama is exactly the point. By keeping the application alive and the business running throughout, by spreading risk across many reversible steps, and by respecting the knowledge embedded in the old code rather than discarding it, the incremental approach turns the daunting prospect of replacing a legacy .NET application into a manageable, ongoing engineering practice rather than a single, perilous bet.
