A legacy .NET platform does not become a rewrite candidate simply because it is old. The real question is whether its current shape prevents the organisation from changing safely, serving customers reliably and responding to new demands.
That distinction matters because rewriting a business-critical system is one of the easiest technology decisions to underestimate. From a distance, the old platform appears to be the problem. Once delivery begins, teams discover that the system also contains years of business rules, operational knowledge, customer-specific behaviour and edge cases that were never fully documented.
The sensible choice is rarely “old versus new”. It is a decision about risk, sequencing and where investment will create the most useful change.
Why full rewrites are so attractive
A rewrite offers a clean story. The organisation can standardise on a current stack, remove awkward dependencies, improve the deployment model and leave decades of accumulated compromises behind. Engineers can design around today’s requirements rather than working within yesterday’s constraints.
That story is appealing because it turns a complicated estate into a single programme with a clear destination. It also creates the impression that technical debt can be removed in one decisive move.
The difficulty is that the old system and the business have usually evolved together. Behaviour may be distributed across application code, stored procedures, scheduled processes, configuration, integrations and manual operational workarounds. Recreating the visible features is not the same as recreating the complete system.
A rewrite therefore starts with an uncomfortable information gap. The existing platform is imperfect but proven in production. The replacement is cleaner but initially understands less about the business. Closing that gap takes longer than most plans assume.
Age is not the deciding factor
Some old systems remain dependable and inexpensive to change. Others have reached a point where every release is slow, risky and dependent on a shrinking pool of knowledge. The age of the technology can contribute to the problem, but age alone does not describe the business impact.
A better assessment looks at changeability. How long does it take to understand and deliver a normal change? Can the team test critical behaviour without relying entirely on manual regression? Are releases repeatable? Are failures visible through useful telemetry? Can a capability be changed without rebuilding and deploying the entire platform?
The answers show whether the platform is merely old or actively restricting the organisation. This is the starting point I use when considering legacy .NET modernisation.
Start with the business-critical journeys
Modernisation plans often begin with an inventory of frameworks, libraries and unsupported components. That work is necessary, but it does not establish priority. A component can be technically outdated without representing the most important risk.
The better starting point is to map the journeys the business cannot afford to lose. In a lending platform, for example, this could include account servicing, payment processing, interest calculation, statements, collections and regulatory reporting. In another domain, the journeys will be different, but the principle is the same.
For each journey, identify the code paths, data, integrations, scheduled work, operational ownership and failure modes involved. This exposes where a seemingly isolated replacement would cross several hidden boundaries.
It also prevents modernisation from becoming a technology-only exercise. A technically elegant change that disrupts a critical operational process is not progress.
When a rewrite may be justified
There are situations where replacement is the correct decision. The current product may no longer match the organisation’s operating model. The platform may depend on technology that cannot be supported safely. Its deployment model may prevent the business from delivering the service customers now expect. The cost of making routine changes may have become consistently higher than rebuilding a clearly bounded capability.
A replacement is also easier to justify when the scope can be made genuinely finite. If the business can define the required outcomes, retire old variations and accept that the new product will not reproduce every historical behaviour, a replacement programme has a much stronger foundation.
The important word is accept. Many rewrite programmes claim they will simplify the product while quietly carrying every old exception into the new system. That is not simplification. It is a port to a different stack, with the added risk of reimplementing years of behaviour.
When incremental modernisation is safer
Incremental modernisation is usually stronger when the platform must continue changing while it is being improved. Customer commitments, regulatory changes and operational fixes do not pause because an architecture programme has started.
Instead of replacing the entire platform, the team creates boundaries around capabilities that can move independently. A new service or web application takes responsibility for a defined slice of behaviour while the existing system continues to handle everything else. Traffic and ownership move gradually as confidence grows.
This is the practical value of the strangler fig pattern. It is not simply a diagram showing old and new systems side by side. It is a sequence of decisions about ownership, data, integration, deployment and rollback. Each extracted capability needs a clear boundary and a credible way to operate alongside the monolith.
The approach is illustrated in my anonymised legacy lending platform case study, where modern .NET, React, REST APIs and Azure-native messaging are being introduced around a long-lived VB6 and .NET Framework estate.
Protect behaviour before replacing it
Legacy code is often difficult to test, but that does not remove the need to understand its behaviour. It makes the need more urgent.
Before moving a critical capability, create enough evidence to compare the old and new paths. Characterisation tests can capture current behaviour even when that behaviour is not ideal. Production telemetry can show volumes, timings and failure patterns. Parallel calculations or shadow processing can compare outputs without immediately changing the customer-facing result.
This work is not glamorous, but it turns modernisation from an act of faith into a controlled engineering process. It also reveals where documentation and assumptions disagree with what the system actually does.
AI-assisted analysis can help teams navigate unfamiliar code, identify dependencies and accelerate repetitive test creation. It does not decide whether the observed behaviour is correct or whether the business should retain it. That judgement still belongs to engineers, product specialists and operational experts. I cover that distinction in more depth in the AI-assisted migration playbook.
Modernise the delivery system as well as the code
A modern runtime does not automatically create a modern engineering system. If releases remain manual, environments differ unpredictably and failures cannot be diagnosed, a framework upgrade will deliver only part of the value.
Build pipelines, automated tests, configuration management, observability and repeatable deployment need to evolve with the application. These capabilities reduce the cost of every subsequent change. They also make smaller releases possible, which is essential when the goal is to reduce risk rather than move it into a single cutover.
This is why an architecture review should consider delivery and operations alongside application structure. The architecture that exists on a diagram is less important than the architecture the organisation can build, release and support.
A practical decision framework
The decision becomes clearer when it is framed around four questions.
What business outcome is currently blocked?
Define the constraint in business terms. Slow release cycles, inability to offer a web experience, fragile integrations and excessive operational effort are clearer than saying the platform is old.
Which capability creates that constraint?
Find the smallest useful boundary. A payment workflow, customer portal or calculation component is easier to reason about than an entire platform.
Can the existing behaviour be observed and protected?
If the team cannot explain, test or compare the current behaviour, the first phase is discovery and protection rather than replacement.
Can value be delivered before the whole programme finishes?
A good modernisation sequence produces useful outcomes along the way. If all value depends on one final migration, the programme carries rewrite-level risk even if it uses incremental language.
The answer may be a combination
Most real estates do not need one universal strategy. Some components can be upgraded in place. Some need to be wrapped behind stable interfaces. Some should be extracted. Others should be retired or replaced entirely.
The goal is not to preserve every old system or to force everything onto the newest platform. It is to create a safer route from the current business reality to a more changeable architecture.
That route should be explicit about risk, ownership and sequencing. It should acknowledge customer commitments and operational constraints rather than treating them as interruptions to technical work. Most importantly, it should allow the organisation to learn before making its largest irreversible decisions.
Start with evidence
The Legacy .NET Modernisation Checklist provides a practical starting point for mapping risk, protecting behaviour and choosing the first valuable boundary.
About Peter French: Peter is a software engineering leader and architect with more than 20 years of experience building and evolving business-critical software, including more than a decade in lending and credit technology. His work spans legacy .NET modernisation, software architecture, Azure delivery, practical AI and engineering leadership.
