Modernizing Legacy .NET Applications Without Starting Over

Why not just rewrite it?

A legacy application is usually ugly for a reason: it encodes years of edge cases, regulatory tweaks and customer-specific fixes that nobody fully remembers. A rewrite has to rediscover every one of them, while new features are frozen and the old system still needs support.

Know where you stand

.NET Framework 4.8.1 is still supported as part of Windows, but it receives fixes rather than new features, and many libraries now target modern .NET only. At the time of writing, .NET 10 is the current long-term support (LTS) release, supported until November 2028; .NET 8 reaches end of support in November 2026, so applications already on .NET 8 have their own upgrade to plan.

dotnet list package --outdated
dotnet list package --vulnerable --include-transitive
dotnet list package --deprecated

Modern equivalents for common legacy pieces

// Before: web.config + static ConfigurationManager, read anywhere
var url = ConfigurationManager.AppSettings["PaymentApiUrl"];

// After: appsettings.json (or an environment variable) bound to a typed class
// appsettings.json  →  { "Payments": { "ApiUrl": "https://..." } }
public class PaymentOptions { public string ApiUrl { get; set; } = ""; }

builder.Services.Configure<PaymentOptions>(builder.Configuration.GetSection("Payments"));

public class PaymentClient(IOptions<PaymentOptions> options)
{
    private readonly string _url = options.Value.ApiUrl;
}

The incremental approach: the strangler fig pattern

Put a new ASP.NET Core application in front of the old one. It serves the routes you have migrated and forwards everything else to the legacy application, so users keep the same URLs and never see a switch. Microsoft documents this approach using the YARP reverse proxy and the System.Web adapters (the Microsoft.AspNetCore.SystemWebAdapters packages), which let the two applications share authentication and session state during the transition.

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddControllersWithViews();
builder.Services.AddHttpForwarder();
builder.Services.AddSystemWebAdapters();   // shared auth/session with the legacy app

var app = builder.Build();
app.UseSystemWebAdapters();
app.MapDefaultControllerRoute();            // migrated routes are handled here...

// ...and anything not migrated yet is forwarded to the legacy application
app.MapForwarder("/{**catch-all}", app.Configuration["ProxyTo"]!);
app.Run();

<PropertyGroup>
  <TargetFrameworks>net48;net10.0</TargetFrameworks>
</PropertyGroup>

A phased plan, with a worked example

The table below is a worked example for a typical order-management system made of four projects: an MVC 5 web app, a business-logic class library, an EF6 data layer and a Windows service that runs nightly jobs.

Pitfalls that catch most teams

• HttpContext.Current everywhere. Static access to the request is common in older code; inject IHttpContextAccessor or pass what is needed explicitly.
• Windows-only APIs. Image processing with System.Drawing, registry access and COM objects need replacements before the app can run on Linux.
• Time zones and culture. Time zone IDs differ between Windows and Linux, and default culture can differ between servers; set both explicitly.
• Authentication during the transition. Plan shared cookies or session from day one, or users will be asked to sign in twice.
• Changing behavior by accident. Characterization tests that pin today's outputs (even odd ones) are what make each step safe.

Moving toward the cloud

Once the application runs on modern .NET it can run on Linux and in containers, which opens simpler and often cheaper hosting: Amazon ECS with Fargate, Azure App Service or Kubernetes. Add structured logging and tracing (for example OpenTelemetry), externalize configuration and secrets, and keep a modular monolith rather than splitting into microservices too early. Our AWS cloud migration guide covers the infrastructure side of the move.