A legacy .NET application is rarely “old code.” It is usually a working business: orders, billing, warehouse movements, or the portal partners still log into. The Framework runtime, the server it lives on, and the UI no one wants to touch are symptoms. The constraint is that the business cannot pause while a new system is imagined in isolation.
Start with an honest map. What does the application do, who depends on it, which data stores are involved, and which integrations would break if it disappeared on a Tuesday? This is not a museum catalog. It is a risk register. Until that exists, estimates are theatre.
Then choose a path per seam, not a single verb for the whole estate. Some components can be rehosted. Some should be replatformed onto modern .NET and cloud infrastructure. A few should be rewritten because the domain has changed. Treating every module as a rewrite is how programs stall.
The strangler pattern remains the most reliable approach for large systems. Identify a boundary — a customer-facing API, a reporting path, a module with painful change cost — and extract it behind a stable interface. Keep the old system serving everything else. Repeat. Each slice should be production-quality, tested, and operable.
Modern .NET, containers, CI/CD and a current frontend are not the goal. They are how you make the next five years of change cheaper. If the modernization does not improve the ability to release, observe and extend the system, it is a migration, not an improvement.
AI can help — with code understanding, test generation and documentation — but it does not remove the need for architecture. An undirected rewrite assisted by a model is still an undirected rewrite.
If you are planning a .NET modernization, budget for discovery, for the first production slice, and for keeping the lights on. The organizations that finish are the ones that ship increments the business can feel, not the ones with the most ambitious target architecture on slide 40.
