Migrating from .NET Framework to .NET 10: how much work it is and how to start

The application on .NET Framework 4.x has been running for ten years. The business runs on it, customers use it and nobody wants to touch it. Then a few things pile up at once: a new library you need no longer supports the Framework, a good candidate turns down the job when they hear what they would be working on, and hosting can’t move to containers or to Linux.

At that point, moving to modern .NET is no longer a question of whether, but of how and in what order.

Is it urgent?

Honestly: it isn’t a fire. .NET Framework 4.8.1 is the last version, and Microsoft supports it for as long as it runs on a supported version of Windows, with no end date announced. Security patches keep coming.

But it’s a dead end. New features, performance and libraries only arrive in modern .NET, and .NET 10 is a long-term support release until November 2028. Every year on the Framework means more code to move later and fewer people who want to maintain it. The cheapest moment to migrate is before something forces you to.

What ports easily, and what doesn’t

Part of the application	How hard	How
Business logic libraries	Easy	Most code works unchanged, with the new project format
Entity Framework 6	Easy	Runs on modern .NET too, and moving to EF Core can come later
Windows Forms and WPF	Medium	They port, but stay Windows-only applications
ASP.NET MVC and Web API	Medium	Controllers are similar, while startup, filters and authentication change
WCF clients	Medium	Client packages exist for modern .NET
WCF services	Harder	CoreWCF, or moving to REST or gRPC
Web Forms	Hardest	It doesn’t exist on modern .NET, so screens are rebuilt, for example in Blazor
AppDomains, Remoting, Code Access Security	Hardest	They don’t exist, so that part has to be designed differently

Most business applications have something from every row, so a real estimate is always the sum of the parts. The table also shows where the bulk of the work is: in the web layer and the old technologies, not in the business logic.

How to start

1. InventoryProjects, packages, dependencies
2. LibrariesBottom up, for both worlds
3. Web layerA new app in front of the old one
4. Switch offThe old part is retired

1. Inventory. Every project, NuGet package and dependency, with the parts from the bottom rows of the table marked. Microsoft’s modernization tool in GitHub Copilot helps find what won’t compile, but the decisions about order are still made by a person.

2. Libraries, bottom up. First the projects nothing depends on, then the ones above them. Each library first moves to the new project format and is then built for both worlds at once. That way the old application keeps working while new code already uses the same libraries:

   <PropertyGroup>
     <TargetFrameworks>net48;net10.0</TargetFrameworks>   <!-- the same library for the old and the new app -->
   </PropertyGroup>

   What is missing on modern .NET and only used on Windows is often covered by Microsoft’s Windows Compatibility Pack, with about twenty thousand APIs.

3. The web layer, piece by piece. A new ASP.NET Core application sits in front of the old one and takes over one route at a time, forwarding everything else to the old app. Users don’t notice the move, sign-in and session are shared, and there is no big day when everything changes at once. For Web Forms it’s the same approach we describe on the page about moving from Web Forms to Blazor.

4. Switch off. When the last route has moved, the old application is switched off, and the libraries can drop the old net48 target.

How much work it is

It depends almost entirely on the web layer and the bottom rows of the table. Business logic libraries are often a matter of days or weeks. A smaller ASP.NET MVC application is usually a matter of weeks, and a large Web Forms application or a system built on WCF services a matter of months, but even then piece by piece, with the application running the whole time.

The most expensive approach is to rewrite everything from scratch and maintain the old system alongside it. Why rewriting from scratch rarely works is in the article on technical debt.

How we work

ProCoding is a .NET studio from Split, Croatia, and modernising old .NET systems is one of the things we do most often. We start with an assessment: an inventory of projects and dependencies, what ports easily, what needs rework and in what order, with a rough effort for each part. The first step is a free 30-minute call.

Sources

• .NET Framework support policy, Microsoft
• Overview of porting from .NET Framework to .NET, Microsoft Learn
• .NET Framework technologies unavailable on .NET, Microsoft Learn
• Use the Windows Compatibility Pack to port code to .NET, Microsoft Learn
• GitHub Copilot app modernization for .NET, Microsoft Learn
• CoreWCF, .NET Foundation