Migrating from .NET Framework to .NET 10: A Practical Roadmap

Modernisation6 min read4 November 2026

Why move now

.NET Framework 4.8.1 is the final version of the original framework. It continues to receive security fixes as part of Windows, but it no longer gains new features, and much of the modern .NET ecosystem, including newer libraries, tooling and hosting options, now targets modern .NET only.

.NET 10 is a long-term support (LTS) release, supported for three years from its launch in November 2025. That makes it a sensible, stable target for applications you expect to run for years to come.

• Performance: modern .NET is significantly faster and uses less memory, which often lowers hosting costs.
• Hosting choice: applications can run on Linux, in containers or on Azure App Service and Container Apps.
• Hiring and support: developers increasingly expect to work with current .NET and tooling.

Step 1: Assess before you change anything

A migration is only as good as the assessment behind it. Start by building an inventory of what you have:

• Projects, target frameworks and how they depend on each other
• Third-party packages, and whether modern versions exist
• Technologies without a direct equivalent, such as Web Forms, WCF server, .NET Remoting and AppDomains
• Hosting, deployment and configuration, including anything tied to IIS or the Windows registry
• Existing automated tests, and the areas with none

Microsoft's .NET Upgrade Assistant can analyse a solution and highlight incompatible APIs, which gives you an evidence-based view of the effort involved.

Step 2: Choose an incremental strategy

Large rewrites are risky and usually take longer than planned. For most business systems, an incremental approach is safer:

1. Move shared libraries first. Retarget class libraries to .NET Standard 2.0 or multi-target them, so both old and new applications can use the same code.
2. Run old and new side by side. For web applications, a reverse proxy such as YARP can route some pages or endpoints to a new ASP.NET Core application while the rest continues to be served by the existing one.
3. Migrate feature by feature. Move one area at a time, test it in production and only then move on.
4. Retire the old application once all traffic is handled by the new one.

This approach, often called the strangler fig pattern, keeps the business running throughout and lets you stop, reprioritise or pause without leaving the system half-broken.

Step 3: Handle the hard parts deliberately

• Web Forms: there is no direct port. Blazor is a natural successor for teams who prefer C# over JavaScript, while Razor Pages or MVC suit simpler, server-rendered screens.
• WCF services: CoreWCF allows many existing services to run on modern .NET with limited change. For new integrations, REST APIs or gRPC are usually a better long-term choice.
• Data access: Entity Framework 6 can run on modern .NET, which lets you move the application first and move to EF Core later.
• Configuration and secrets: replace web.config settings with modern configuration and a proper secret store such as Azure Key Vault.

Step 4: Protect behaviour with tests

Before moving a feature, add tests that capture how it behaves today, including edge cases the business relies on. These tests become your safety net: if they pass on the new version, you can deploy with confidence.

Step 5: Automate deployment and monitor the cut-over

Set up a CI/CD pipeline early so every change is built, tested and deployed the same way. Add application monitoring before you switch traffic, so performance or error changes are visible straight away and you can roll back quickly if needed.