Updated 7 October 2026: Microsoft has officially deprecated the .NET Upgrade Assistant and now recommends the GitHub Copilot upgrade agent in Visual Studio instead. Step 2 of the migration has been updated accordingly.
Many SMBs run a central application that has worked for years: an order system, a customer portal, an internal tool. Often on .NET Framework, often "it still runs". Until it doesn't anymore, or nobody wants to do updates. The question then is: modernize, rebuild or leave as is?
The three honest options
- Keep running: legitimate when the application is stable, contained, and free of security or staffing risk.
- Modernize (migrate): step by step onto current .NET without throwing away the business logic. Usually the best cost-benefit ratio.
- Rebuild: only when the legacy burden suffocates the business logic. Expensive and risky; rarely the first choice.
My rule of thumb: when in doubt, migrate rather than rebuild. A working system contains years of accumulated domain knowledge. You don't throw that away without a very good reason.
Where .NET really stands (as of May 2026)
Some facts help with the assessment:
- .NET 10 is the current LTS version (released November 2025, supported until November 2028). That is the sensible migration target.
- .NET 8 and .NET 9 reach end of support already on 10 November 2026, so if you're there, plan the jump to .NET 10.
- .NET Framework 4.8 / 4.8.1 has no fixed end of support; it stays tied to the respective Windows version. So it doesn't "die", but it gets no new features. The pressure here comes not from an end date but from stagnation.
How to recognize real pressure to act
- The platform/runtime in use no longer receives security updates
- Nobody around can or wants to touch the code anymore
- Every small change takes disproportionately long
- Connecting to modern services (cloud, auth, APIs) is impossible
If none of these apply, "keep running" is a serious decision, not a failure.
Migration without a big bang
The mistake is almost always the "big rewrite". Lower-risk is an incremental approach (often called "Strangler Fig"):
- Secure the baseline: put automated tests around the critical flows so regressions surface immediately.
- Analyze: Microsoft now recommends the GitHub Copilot upgrade agent, which is included in Visual Studio; the former .NET Upgrade Assistant is officially deprecated. The agent analyzes projects and dependencies and produces a step-by-step migration plan.
- Lift step by step: module by module onto current .NET; after each step the application stays runnable and is shipped.
- Renew infrastructure, preserve business logic: the valuable part is the domain logic. It stays, only the surroundings get modern.
A typical course looks like this: first migrate a contained, low-risk component (gather experience, sharpen the approach), then the central modules, finally the edges. Each step is usable on its own. There's never one big, dangerous cutover date.
What it costs and what standstill costs
Modernization is an investment. The honest counter-calculation isn't "cost vs. 0" but "cost vs. risk": production outage, security gap, dependence on a single person who still understands the system.
Conclusion
Not every legacy application has to be touched, but every one should be consciously assessed. "It still runs" is a decision; it should just be an informed one.
Have such an application and want an honest assessment? In a free initial consultation I'll place your situation in context, without sales pressure.
Note: The articles on this blog are produced with the help of AI and are editorially reviewed before publication. Editorial responsibility lies with Emre Yurtbay (see the legal notice).