Migrating .NET Framework to .NET 10: a practical guide
Many businesses still run important systems on ASP.NET MVC, Web API or Web Forms built for .NET Framework 4.x. Moving them to modern .NET rarely needs a rewrite, but it does need a plan.
Why move at all?
.NET Framework 4.8 is still supported as part of Windows, so there's no hard deadline. The reasons to move are practical:
- It's frozen. No new features or performance work, and new libraries increasingly target modern .NET only.
- Hosting cost. Framework apps need Windows and IIS. Modern .NET runs on Linux, in containers and on cheaper cloud services.
- Performance. Modern ASP.NET Core is typically far faster than classic ASP.NET on the same hardware, which often means fewer servers.
- People. Developers want to work on current technology, and Framework skills are getting harder to find.
What changes, and what doesn't
| Area | What happens |
|---|---|
| Business logic and class libraries | Usually moves across with little change |
| ASP.NET MVC and Web API | Maps closely onto ASP.NET Core MVC. Controllers and views need adjusting, not rewriting |
| Entity Framework 6 | EF6 runs on modern .NET, so data access can be moved first and migrated to EF Core later if needed |
| Web Forms | No direct equivalent. Pages are rebuilt in Razor Pages or Blazor, one area at a time |
| WCF services | Move to CoreWCF to keep existing clients working, or to REST or gRPC |
System.Web, HttpContext.Current, web.config settings | Replaced by ASP.NET Core equivalents. This is where most of the work is |
Migrate in stages, not in one big bang
The safest approach for a live system is incremental migration, sometimes called the "strangler fig" pattern:
- Put a new ASP.NET Core app in front of the existing one, using a reverse proxy such as Microsoft's YARP. Every request still goes to the old app at first.
- Move shared libraries to target .NET Standard or modern .NET so both apps can use them.
- Move one area at a time, for example reporting and then customer accounts, and route those URLs to the new app.
- Share sessions and authentication between old and new apps while both are running. Microsoft's System.Web adapters exist for exactly this.
- Retire the old app once nothing routes to it.
Users keep working throughout, each step can be tested and released on its own, and the business can pause between stages.
Common surprises
- Third-party components with no modern .NET version, such as old reporting tools, PDF libraries and UI control suites.
- Windows-specific code: the registry, COM,
System.Drawing. Some of it works via the Windows Compatibility Pack, some needs replacing. - Configuration and secrets buried in
web.configtransforms. - Authentication: Forms or Windows authentication usually moves to ASP.NET Core Identity or an external identity provider.
Where to start
The first step is an honest assessment: what the application depends on, which parts are risky, and the order in which to move them. My fixed-price .NET upgrade audit gives you exactly that, including a costed migration plan. If you're on .NET 8 or 9 rather than Framework, see .NET 8 end of support: what to do.