.NET Framework 4.8 still runs an enormous amount of enterprise software, and it is not going anywhere by itself: it ships with Windows, it is serviced, but it is frozen. Everything new in the .NET ecosystem (performance, cross-platform hosting, container density, current C# language features, actively evolving libraries) happens on modern .NET. Moving a large estate from .NET Framework to .NET 8+ is now a well-understood problem with genuinely different tooling philosophies behind it. This is a map of the realistic options for an enterprise-scale migration, and where each one fits.
The short version
| Platform | Approach | Best fit | Main limitation |
|---|---|---|---|
| Microsoft .NET Upgrade Assistant | Free, in-place, assisted upgrade | Single solutions, straightforward services | Manual effort scales with estate size; no program-level orchestration |
| GitHub Copilot app modernization | Agent-assisted upgrade inside the GitHub/VS ecosystem | Teams standardized on GitHub/Azure | Developer-driven, task by task; verification stays on you |
| AWS Transform for .NET | Managed porting of .NET Framework to cross-platform .NET | AWS-bound estates, Windows-to-Linux cost reduction | AWS as the destination; less fit for on-prem or neutral targets |
| Moderne | Deterministic recipes over a semantic model, C# support | Fleet-wide, repeatable changes across many repos | Changes must be expressible as recipes; open-ended rewrites are out of scope |
| Morph by Modelcode | Spec-driven migration program with functional verification | Migrations that combine the framework jump with architectural change | Program-style overhead is unnecessary for small, simple upgrades |
| vFunction | Architectural analysis and decomposition | Untangling a monolith before or during the move | Decomposition tool, not an end-to-end code migrator |
| CAST Imaging | Deep structural analysis and dependency mapping | Understanding what you own before committing | Analysis only; pairs with an execution tool |
What actually makes .NET Framework migrations hard
The upgrade guides make it look mechanical: retarget the project files, swap packages.config for PackageReference, replace System.Web. On one service, it is. On three hundred services accumulated since 2008, the hard part is everything around the code: WCF endpoints with no modern equivalent chosen yet, IIS-specific behavior, AppDomain assumptions, third-party dependencies stuck on Framework, and business logic nobody has exercised in years. The tooling question is really a question about how much of that surrounding work you want handled inside a managed process versus by your own teams.
The options in more detail
Microsoft .NET Upgrade Assistant is the honest starting point and the right answer for a meaningful share of estates. It analyzes projects, applies known transformations, and flags what it cannot do. It is free and Microsoft-maintained. Its model is per-solution and developer-driven: on a large estate, it tells each team what to do, but nothing coordinates the program, sequences the risk, or proves behavior was preserved.
GitHub Copilot's app modernization capabilities push the same motion further with agents that plan and execute upgrade tasks. If your organization already lives in GitHub and Visual Studio, this is the lowest-friction way to accelerate individual teams. It remains a per-repo, developer-in-the-loop motion: the aggregate program (order, dependencies between services, estate-level verification) is still yours to run.
AWS Transform for .NET is the strongest managed option when the destination is AWS and the goal includes leaving Windows licensing behind. It ports .NET Framework applications to cross-platform .NET at scale, with real automation around the repetitive work. The trade-off is directional: it is built to move you into AWS. For on-prem targets or cloud-neutral strategies, it is the wrong shape.
Moderne comes at the problem from deterministic automated refactoring: a compiler-accurate model of the code, with recipes that apply the same change identically across hundreds of repositories, and C# support in its platform. For the mechanical layer of a .NET migration repeated across a large fleet (API replacements, dependency bumps, pattern rewrites), determinism is a real guarantee: the same recipe produces the same result everywhere. What it does not attempt is the open-ended part, where the target architecture has to be designed rather than derived from a rule.
Morph by Modelcode treats the migration as a governed program rather than a series of tasks. It analyzes the repositories, produces a Project Spec a human must approve before any code is generated, executes in milestones delivered as pull requests, and runs functional verification comparing the migrated system's behavior against the original. C# is a supported language and Windows runtimes are supported alongside Linux, including through ModelDaemon for code that cannot leave your infrastructure. Where this model earns its overhead is when the framework jump is entangled with bigger changes: a monolith being decomposed on the way to modern .NET, services being restructured across repositories, or behavior-critical systems where "it compiles and the tests we happen to have pass" is not enough evidence to ship. Modelcode has published functional-verification results on repository-scale migration in its RepoMod-Bench work (paper on arXiv), which is candid about how hard full autonomy is at scale: the honest conclusion is that verification and human gates are what make large migrations shippable, and that is the design. For a small, clean solution, this is more process than you need; the Upgrade Assistant will get you there faster.
vFunction answers a different question: not "how do I change the code" but "what should the target architecture be". It analyzes a running monolith, maps the real dependency structure, and proposes service boundaries. Many .NET Framework estates are monoliths whose migration is the natural moment to decompose; vFunction pairs well with an execution platform rather than replacing one.
CAST Imaging sits earlier still: deep structural analysis and dependency mapping across very large, mixed estates. Enterprises use it to decide what to migrate, retire, or leave alone before committing budget. It executes nothing, by design.
How to choose
Ask three questions. First, is the destination fixed? AWS-bound estates have a purpose-built option; neutral targets need cloud-agnostic tooling. Second, can the change be fully specified in advance? Rule-expressible changes at fleet scale favor deterministic recipes; migrations whose target has to be designed favor a spec-and-verify program. Third, what evidence do you need before shipping? If behavioral equivalence must be demonstrated, not assumed, pick tooling where verification is a first-class output rather than an afterthought.
Most large .NET programs end up combining tools: analysis to scope it, deterministic automation for the repeatable layer, a governed migration platform for the entangled core, and the free Microsoft tooling everywhere it is sufficient. The estates that get into trouble are the ones that pick a single tool first and discover its shape second.
Related: AWS Transform Alternatives in 2026 · Morph's supported architectures and case studies · RepoMod-Bench on arXiv
