Your internal core business applications run on .NET Framework, operating smoothly without major flaws. For years, vendors have insisted that "it's time to migrate," yet justifying substantial expenditure for systems that haven't stopped running is difficult to rationalize internally. Support hasn't expired yet, either. Consequently, the project gets deferred to the next fiscal term year after year.
Choosing to maintain existing systems requires verifying support status. Support for .NET Framework 4.8.1 follows the lifecycle of the host Windows operating system on which it is installed. Not all operating environments remain supported into 2031 and beyond; you must identify the exact OS version and edition to confirm deadlines. The real challenge is that systems often become unviable from adjacent dependencies long before the OS deadline arrives.
On September 8, 2026, .NET 11 RC1 was released, with general availability scheduled for November of the same year. Using this milestone, we outline the criteria and timing for taking action on business systems whose modernization has been repeatedly postponed.
Surrounding ecosystems abandon the platform before official end-of-life
.NET Framework itself will not abruptly halt. What stops is everything around it.
First are the libraries. You must check each dependent package to see whether it will continue providing updates targeting net48. Once support is dropped, you will no longer be able to install newer versions of that library. The real risk is not missing features, but security fixes. When vulnerabilities are discovered, if patched releases are only shipped for modern runtime targets, you are forced to consider replacing packages, migrating runtimes, or implementing compensating controls. Short remediation windows severely restrict your options for investigation and testing.
Next is the runtime hosting environment. Modern .NET has become the default target when spinning up new cloud application platforms. While "keeping existing environments running as-is" remains possible, options that align with modern hosting architectures steadily diminish.
Finally, there is the human element. Implementation patterns unique to .NET Framework require engineering personnel with relevant legacy experience. You must also verify whether you can retain developers and partner firms capable of undertaking maintenance. This is a procurement problem rather than a technical one, making it vital to confirm maintenance scope and pricing while options for service providers remain open.
In summary, the key decision criterion is not the official support end date, but "whether you can choose when to act before your options run out."
What changes in .NET 11
When evaluated as a target migration platform, three highlights stand out in the .NET 11 release candidate:
- Runtime async enhancements: A mechanism was introduced to JIT-compile runtime-side asynchronous versions of methods that synchronously return tasks. In addition, optimizations have been added to omit capturing
ExecutionContextwhen ambient state is unused. - Removal of processor count ceilings: Machines with massive core counts can now be leveraged directly.
- AOT compiler improvements: Generated native binaries are faster and more compact, achieved partly by consolidating multiple interface calls through shared dispatch.
In the context of business systems, the first and third enhancements are particularly impactful. The first improves throughput and response latency for internal web applications experiencing high concurrency. The third improves cold-start times when running inside containers thanks to faster initialization and reduced deployment footprint.
However, to be honest, these features rarely serve as deciding reasons to migrate. While faster performance is welcome, it is a weak motivation to rebuild and migrate systems that are not currently causing issues. Migration decisions should be made based on the factors discussed in the previous section—"the surrounding ecosystem moving on." Improvements in .NET 11 should instead be treated as part of choosing a migration target, under the mindset of "if we are going to migrate anyway, let's pick this generation." Rather than immediately moving production workloads to a release candidate, compare supported LTS versions, required features, OS and library compatibility, and the budget for the next update cycle.
It is a full re-platforming, not a simple version upgrade
This is the biggest reason for discrepancies in cost estimates. Migrating from .NET Framework 4.8 to modern .NET is not a task of simply bumping a project's version number; it is a task of replacing the underlying foundation.
The areas you will need to touch generally break down into the following five:
| Area | Consequence |
|---|---|
| Project format | Rewrite legacy csproj files into the SDK-style format |
| Web stack | Replace System.Web-based implementations with ASP.NET Core |
| Data access | Verify EF6 versions and provider compatibility; evaluate whether migrating to EF Core is necessary |
| Communications | Distinguish between WCF servers and clients, and evaluate supported libraries, CoreWCF, or converting to Web APIs |
| Unsupported or modified APIs | Review feature by feature, such as the deprecation of BinaryFormatter or the creation of additional AppDomains |
Among these, estimating the workload for the last two is particularly difficult. When connecting to external systems via WCF, you cannot make decisions alone because the external counterparty's schedule and constraints are involved. If BinaryFormatter is used for persisting sessions or caches, its scope of impact is broad, and work begins by locating where it is used across the codebase.
Conversely, while the top three require a substantial volume of work, their estimates are easier to forecast. When requesting an estimate, scoping out an initial investigation for the bottom two items first will significantly improve the accuracy of the overall cost. Requesting a lump-sum estimate upfront will drive up the price due to buffers added for uncertainties.
Consider three options: full migration, partial migration, or leaving as-is
Migrating everything all at once is not the only option. In practice, you combine the following three approaches:
- Full migration. Re-platform the entire system onto modern .NET. This is the straightforward choice for small-scale systems or applications where you plan to keep adding features.
- Partial migration. Extract only external connections or frequently changed modules to the new stack first, while leaving the rest running as-is for now. This is a practical solution when a budget for full migration cannot be secured all at once.
- Leaving as-is. For systems that undergo almost no modifications, have no external connections, and can be frozen alongside their runtime environments, deliberately deciding not to touch them is also a valid choice.
Set strict criteria when choosing the third option. Beyond network exposure, verify OS and dependency package support, patch application status, backups, and recovery procedures. Simply using a supported version of .NET Framework with an internet connection does not guarantee you will continue receiving fixes. Conversely, running in an isolated network does not make end-of-support software safe.
Whichever option you choose, making a sound decision requires taking inventory of the current state. Which libraries do you depend on? Which ones have dropped net48? Where are the external connections? Debating whether to pursue a full migration or leave systems as-is without this information will never lead to a conclusion. While approaches for using AI to compress the migration workload itself are outlined in Shrinking legacy migration from years to weeks, taking inventory remains an essential prerequisite.
The identical generational shift taking place in mobile applications is covered in .NET MAUI moves away from Mono, while strategies for repaying technical debt incrementally rather than all at once are discussed in Continuous modernization.
What to do next
You do not need to finalize your migration decision during this fiscal year. What you must decide is when to assemble the materials required to make that decision.
Specifically, work begins by generating a list of dependency packages and checking whether each one supports modern .NET. The time required for this investigation varies depending on your architecture. Even if you choose to maintain the existing setup, record that decision along with set review dates and criteria. This investigation does not guarantee future zero-defect operation. However, postponing without investigating versus postponing after a thorough assessment makes an enormous difference when explaining plans for the next fiscal year.
At GleamHub, our custom development, AI, and automation consulting services support migration evaluations for business systems including .NET, dependency inventorying, and partial migration architecture design. Available approaches differ depending on your existing system architecture and external connections, so please reach out individually via Contact Us.
