Describe the intended benefit more precisely
“The system is old” can mean several things: its runtime will soon stop receiving updates, a business department waits too long for changes, or each new feature touches so many areas that the team can no longer plan reliably.
These problems call for different responses. A version upgrade can address support without fundamentally restructuring the application. Better module boundaries can make development easier without replacing the user interface.
Before choosing an approach, I would complete one sentence: after modernisation, we can do something that is too expensive, too slow, or too risky today. The more specific the sentence, the easier it becomes to compare options.
A support deadline limits the first step
Support for .NET 8 and .NET 9 ends on November 10, 2026. After that date, Microsoft will not provide further security updates for these versions and recommends .NET 10 as the migration target. This is a time-bound reason to act, not an automatic case for a complete rebuild. Microsoft's announcement
If a bounded version upgrade can restore a supported operating position, I would plan that scope separately. Replacing a central library belongs in scope if the upgrade requires it. A new frontend belongs there only if it is genuinely necessary for that move.
The objective is a dependable first step. Broader improvements then need their own priorities and resources.
When a rebuild deserves serious consideration
A rebuild can make sense when the existing application serves a clearly bounded purpose and its current rules are sufficiently understood. A platform whose essential technical foundations are no longer available may also require a more substantial replacement.
I would examine a rebuild particularly closely when these questions can be answered:
- Which actively used functions must the replacement provide?
- Which data must be migrated, and at what quality?
- Which consumers and workflows depend on the existing application?
- Who maintains the old system until retirement?
- How will we know that replacement is complete?
A small tool with few users and a well-defined dataset is a different case from a portal whose exceptions have accumulated in code and operating procedures over years.
A rebuild does not automatically provide a clean starting point. Unknown rules still have to be discovered. A new programming language does not do that work.
When incremental modernisation becomes easier to plan
An incremental approach is attractive when the existing system still delivers value and a useful area can be separated along an understandable boundary. The first step should help on its own, for example by reducing a long wait or recurring manual work.
The Strangler Fig pattern describes gradual replacement: some functionality moves to a new solution while the remainder initially continues running. It offers one structure for the transition, not a guarantee of low cost.
The harder question is often how long two paths must coexist. During that period, access, data, and failures must be understood across both sides. If nobody retires the old version, the transition becomes a permanent additional burden.
An example involving document search
Suppose a customer portal works in daily operations, but document search is slow and difficult to extend. This is a hypothetical example.
A complete rebuild would bring authentication, permissions, order processing, and many rare workflows into scope alongside search. That may be necessary eventually. For the immediate search problem, it would initially be a large undertaking.
As a bounded experiment, I would consider a new search path for a clearly defined document area. The team would need to establish where the data comes from, how fresh the search index must be, which permissions must apply, and how to measure whether users find their documents more effectively.
A new search interface alone would be insufficient. The experiment needs to cover the actual workflow and show under realistic conditions whether the proposed boundary works.
Budget for the transition
When comparing options, I would estimate the new implementation and the transition separately. Transition work includes data migration, test cases, consumer changes, and removing old paths.
Write ownership is particularly important. If two applications can change the same business data, there must be a clear rule for the authoritative state and conflict handling. Unplanned duplicate maintenance would make me reconsider the scope.
The same applies to recovery. After a data change, merely starting an older application version may be insufficient. Before switching over, establish which states must remain compatible and how incorrect changes can be corrected.
Start with a short decision record
I would describe both options on the same basis: expected benefit, the first production step, necessary transition work, and the conditions for retiring the old path.
Include one deliberately uncomfortable question: if the initiative ends after the first step, will we have an improvement or simply another unfinished solution?
A bounded rebuild can answer that question well. An incremental migration can fail it. The method's label does not determine success; what matters is whether the scope fits the available knowledge and capacity.
Help with the decision
I help companies plan modernisation in their .NET environments around concrete problems. If you are weighing up a version upgrade, incremental replacement, and a rebuild, we can narrow down a useful first step in a free introductory call.