The board wants an AI roadmap. Your best engineers want to build it. And the thing standing in the way isn’t budget or headcount — it’s a fifteen-year-old application that nobody fully understands and nobody dares switch off.
That’s the quiet crisis in a lot of engineering orgs right now. For years, legacy was a maintenance line item: keep it patched, keep it breathing, don’t rock the boat. In 2026 it’s something sharper. It’s the reason the AI initiative stalls. Predictive models need clean data and event streams. Copilots need APIs to call. Automation needs decoupled services it can orchestrate. A monolith with business logic buried in stored procedures and a UI written before responsive design was a thing gives you none of that.
So the pressure is real, and it lands on the CTO’s desk as a single uncomfortable question: how do we modernise the core system that runs the business, while it’s still running the business?
The honest answer is that you don’t get to choose between a risky big-bang rewrite and standing still. There’s a third path, and it’s the one that actually ships. This piece walks through how to modernise a legacy enterprise application without downtime — the strategy, the sequencing, and the .NET and Blazor specifics — using a transportation management system as the through-line, because logistics is one of those domains where “we’ll take it down for a maintenance window” is not a sentence you get to say.
The rewrite that never ships
Start with what fails, because most teams reach for it first.
The instinct when you inherit a painful legacy codebase is to rebuild it clean. New stack, new architecture, no compromises. It feels decisive. It’s also how you end up two years and several million dollars in, with a half-finished replacement that still can’t do the seventeen edge cases the old system handles quietly every night.
The problem is structural, not a matter of willpower. The old system keeps changing while you rebuild — the business doesn’t freeze feature requests because engineering is busy. You’re chasing a moving target with an incomplete map. Worse, the moment you split the team into “keep the lights on” and “build the future,” you’ve created two systems, two priorities, and a widening gap between them. This is the classic second-system trap, and greenfield rewrites of business-critical software fail far more often than they succeed.
Zero-downtime modernisation flips the risk model. Instead of one enormous, irreversible cutover, you make a long series of small, reversible changes — each one shippable, each one testable against the live system, each one easy to roll back if the numbers look wrong. That’s the whole game. Legacy system replacement risk mitigation isn’t a phase you run at the end; it’s a property of how you sequence the work from day one.
The case: a 3PL running a live TMS
Picture a mid-sized third-party logistics provider. Their transportation management system is the operational heart of the company — it runs the load board, assigns carriers, calculates rates, tracks shipments, and generates invoices. It’s an ASP.NET Web Forms application, roughly a million lines, backed by one large SQL Server database with a decade of stored-procedure logic layered into it.
It runs 24/7 because freight moves at 3 a.m. A dispatcher in one time zone is booking a load while a driver in another is checking in at a dock. Downtime here isn’t an inconvenience — a missed pickup is an SLA penalty, an unhappy shipper, and sometimes a truck sitting idle burning money. “Take it offline for the weekend” was never on the table.
And leadership wants more from it: predictive ETAs, automated carrier matching, dynamic pricing that reacts to lane demand. Every one of those needs data and interfaces the monolith doesn’t expose. The TMS isn’t just old — it’s the bottleneck on the company’s entire AI ambition. This is the exact situation where brownfield application development stops being a technical nicety and becomes the strategy.
Here’s how you take it apart without stopping the trucks.
The strangler fig, and why it’s the backbone
The core pattern for this is the strangler fig, named after the tree that grows around a host, gradually enveloping it until the original is gone and the fig stands on its own. Applied to software, you grow a new system around the old one, intercepting and replacing its behaviour slice by slice, until one day the legacy application has nothing left to do and you quietly retire it.
The strangler fig pattern migration is powerful because at no single point is there a dramatic switch. The old system serves production traffic on Monday, serves slightly less on Tuesday, and keeps shrinking. If a slice misbehaves, you route back to the original in seconds. You’re never betting the company on one deployment.
Everything below is a mechanic in service of that pattern.
Step 1: Put a seam in front of the monolith
You can’t strangle what you can’t intercept. The first move — before you rewrite a single screen — is to place a routing layer in front of the application so that every request passes through something you control.
In the .NET world, YARP (Yet Another Reverse Proxy) is the natural fit. You stand it up in front of the TMS and, initially, it forwards 100% of traffic straight through. Nothing changes for users. But now you own the front door.
// Program.cs — a reverse proxy that fronts the legacy TMS.
// Day one: everything goes to the monolith. Nothing has changed for users.
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddReverseProxy()
.LoadFromMemory(
routes: new[]
{
new RouteConfig
{
RouteId = “legacy-tms”,
ClusterId = “legacy”,
Match = new RouteMatch { Path = “{**catchall}” }
}
},
clusters: new[]
{
new ClusterConfig
{
ClusterId = “legacy”,
Destinations = new Dictionary<string, DestinationConfig>
{
[“monolith”] = new() { Address = “https://tms-legacy.internal/” }
}
}
});
var app = builder.Build();
app.MapReverseProxy();
app.Run();
This is the foundation of an API-first modernisation approach. Once traffic flows through a layer you control, you can redirect individual paths — /rates, /carriers, /tracking — to new services the moment they’re ready, and leave everything else untouched.
Step 2: Carve the first slice
Choosing what to migrate first matters more than how. Don’t start with the scariest module, and don’t start with a trivial one nobody cares about. Pick something well-bounded, valuable, and read-heavy enough to be low-risk.
In the TMS, rate calculation is a strong first candidate. It has clear inputs and outputs, it’s queried constantly, and exposing it as a clean API immediately unlocks value for other teams. It’s a good place to begin the shift from monolith to services — and to prove the pattern works before you touch anything harder.
The trap in legacy code refactoring for an enterprise application is that you don’t actually know what the old code does. The specification is the behaviour, quirks included. So before you rewrite the logic, you pin it down with characterisation tests: capture real inputs and their real outputs from the running system, and make the new service match them exactly.
// Characterisation tests capture what the legacy engine ACTUALLY does,
// bugs and all, so the new service is provably equivalent before it goes live.
[Theory]
[MemberData(nameof(ProductionRateSamples))] // replayed from real, logged requests
public async Task NewRateEngine_MatchesLegacy(RateRequest req, decimal legacyResult)
{
var actual = await _newRateEngine.QuoteAsync(req);
Assert.Equal(legacyResult, actual, precision: 2);
}
Then the new slice ships as a focused minimal API:
app.MapPost(“/api/rates/quote”, async (RateRequest req, IRateEngine engine) =>
{
var quote = await engine.QuoteAsync(req);
return Results.Ok(quote);
});
When the tests are green against thousands of replayed production requests, you flip that one path at the proxy. /api/rates/* now hits the new service; everything else still runs on the monolith. That’s your first strangled branch — and the .NET legacy application migration has officially started, with zero downtime and a rollback that’s one config line away.
Step 3: The data problem (this is the hard part)
Anyone who’s done this will tell you the code is the easy half. The shared database is the anchor that holds the monolith in place, and untangling it is where zero-downtime refactoring earns its name.
You cannot flip a switch on data. What you do instead is run old and new in parallel and compare them until you trust the new path. The safe sequence looks like this:
Shadow reads first. When a rate request comes in, serve the answer from the legacy engine as always — but also call the new engine in the background and log any difference. Users see the trusted result; you accumulate evidence.
public async Task<Quote> GetQuoteAsync(RateRequest req)
{
var legacy = await _legacyEngine.QuoteAsync(req);
// Shadow call — result is never served, only compared.
_ = Task.Run(async () =>
{
try
{
var candidate = await _newEngine.QuoteAsync(req);
if (candidate.Amount != legacy.Amount)
_log.Warning(“Rate mismatch {Req}: legacy {L} vs new {N}”,
req, legacy.Amount, candidate.Amount);
}
catch (Exception ex) { _log.Error(ex, “Shadow rate failed”); }
});
return legacy;
}
Then flip the read, gated by a feature flag. Once the mismatch rate sits at effectively zero for long enough, a flag lets you promote the new engine to primary — and demote it instantly if production surprises you.
public async Task<Quote> GetQuoteAsync(RateRequest req) =>
await _flags.IsEnabledAsync(“rates.new-engine”)
? await _newEngine.QuoteAsync(req)
: await _legacyEngine.QuoteAsync(req);
For writes, dual-write or use change data capture. When the new service starts owning data, it either writes to both stores during a transition window (expand, migrate, contract), or you stream changes out of the legacy database with CDC so the new side stays current without the monolith knowing it’s being watched. Either way, the two systems agree throughout, and there’s never a moment where the data has to be “down” to move.
The discipline here — parallel run, compare, gate, promote — is what lets you refactor a monolith toward microservices one bounded context at a time without a single risky cutover.
Step 4: Rebuild the UI with Blazor
While the services get carved out underneath, the interface needs to come forward too — and this is where teams overreach. You don’t rewrite every screen at once. You migrate the UI the same way you migrate everything else: one route at a time, behind the same proxy.
Blazor is the pragmatic destination for a .NET shop, because it lets your team build a modern web front end in C# rather than standing up a separate JavaScript stack and the hiring headache that comes with it. On .NET 10, the current long-term-support release, the render-mode model is mature enough to make sensible per-screen choices, and a few Blazor .NET migration best practices matter more than the rest.
Match the render mode to the screen. For an internal operations tool like a dispatcher’s rate console — authenticated, behind the firewall, latency-tolerant — Interactive Server is usually the right call: no large WebAssembly download, server-side compute, instant startup. For screens you might later expose to carriers or customers, Interactive Auto gives you a fast server-rendered first load that transparently upgrades to WebAssembly. Static SSR suits read-only, SEO-relevant pages that don’t need interactivity at all.
Use the .NET 10 persistent-state attribute. Prerendering makes the first paint fast, but it used to mean your component fetched its data twice — once to prerender, once when it went interactive — with a visible flicker in between. That’s now a single attribute instead of a pile of boilerplate.
@page “/rates/quote”
@rendermode InteractiveServer
<RateQuoteForm Lanes=”Lanes” OnQuote=”HandleQuote” />
@code {
// .NET 10: state captured during prerender is restored on the
// interactive render — no second fetch, no flicker.
[SupplyParameterFromPersistentComponentState]
public List<Lane>? Lanes { get; set; }
protected override async Task OnInitializedAsync()
{
Lanes ??= await LaneService.GetActiveLanesAsync();
}
}
At the proxy, /rates/* now serves the Blazor app while /loads/* still serves the Web Forms monolith. Shared authentication — a common cookie or OIDC via your identity provider — means dispatchers move between old and new screens without noticing the seam. To them it’s one application. Under the hood, the fig is spreading.
Continuous delivery is the enabler, not a nice-to-have
None of this works if shipping is a monthly event. Incremental migration lives or dies on how fast you can deploy and, more importantly, how fast you can roll back. Continuous delivery for legacy systems is the machinery that makes small reversible steps possible in the first place.
Two practices carry most of the weight. Blue-green or canary deployments let you release a new slice to a fraction of traffic and watch it before it reaches everyone. Feature flags — which you’ve already seen doing the data cutover — decouple deploying code from releasing behaviour, so a risky change can sit dark in production until you’re ready and be switched off without a redeploy.
And you can’t manage what you can’t see. Structured logs, metrics, and distributed traces that span both the old and new systems are what let you compare the shadow calls, catch the rate mismatches, and prove a slice is safe before you promote it. Observability isn’t decoration on a modernisation programme — it’s the instrument panel you’re flying by.
The payoff: this is the AI on-ramp
Come back to where we started. The board asked for AI, and the legacy system was the thing in the way.
Watch what the strangler work has quietly produced. The rate engine is a clean API. Shipment tracking emits events. Carrier data has a service in front of it instead of a stored procedure behind it. The predictive-ETA model now has a tracking stream to read. The carrier-matching engine has structured assignment data to learn from. Dynamic pricing has a rate API it can plug into. None of that was reachable inside the Web Forms monolith — and none of it required a big-bang rewrite to expose.
That’s the reframe worth taking to leadership. Legacy modernisation isn’t a cost centre you tolerate to keep old software alive. Done as a strangler-fig strategy, it’s the prerequisite for everything the business is already asking for. Every slice you carve out doesn’t just reduce risk and technical debt — it hands your data and AI teams another interface to build on. This is exactly why the strongest enterprise software modernisation case studies from the last couple of years read less like IT clean-up projects and more like the opening chapter of an AI strategy.
The trucks never stopped. The dispatchers never noticed. And the system that was blocking the roadmap became the platform it runs on.
Modernising a live, business-critical system is as much about sequencing and risk discipline as it is about the stack you land on. If you’re mapping out a zero-downtime path for a legacy .NET application — or trying to work out which slice to strangle first — that first architectural decision is worth getting right before a line of code is written.