Many business applications still run on .NET Framework 4.x. They work, but they are standing still. .NET Framework 4.8.1 is the final version: it receives security fixes as part of Windows, but no new features, and new libraries increasingly target modern .NET only. This plan shows how to migrate a .NET Framework application to modern .NET without stopping the business that depends on it.

Why migrate now

  • Performance. ASP.NET Core and modern .NET are much faster than the classic stack, which often means smaller servers and quicker pages.
  • Hosting choice. Run on Windows or Linux, on IIS, in containers or on any major cloud.
  • Long-term support. A new .NET version ships every November, and the even-numbered ones are long-term support (LTS) releases with three years of updates. .NET 10, released in November 2025, is the current LTS release.
  • Hiring. Developers want to work with current tools, and modern .NET skills are easier to find.

If your application already runs on .NET 8, plan its upgrade too: support for .NET 8 ends in November 2026. Moving from .NET 8 to .NET 10 is usually a much smaller job than leaving .NET Framework.

Step 1: Assess what you have

Make an inventory before you change anything:

  • Every project in the solution, its type and its target framework.
  • NuGet packages, and whether each has a modern .NET version or a replacement.
  • Technologies with no direct equivalent: ASP.NET Web Forms, WCF services, Windows Workflow, .NET Remoting.
  • Windows-specific dependencies such as the registry, COM components and System.Drawing on servers.
  • How the app is built, tested and deployed today.

Step 2: Choose a migration path

In-place upgrade

Class libraries and many ASP.NET MVC or Web API projects can be upgraded project by project. Microsoft's upgrade tooling in Visual Studio converts project files and flags many API changes. This suits small and medium applications with a modest number of dependencies.

Incremental migration

Large applications are safer to move piece by piece. A modern ASP.NET Core application sits in front of the old one, with a reverse proxy such as YARP, and takes over routes one at a time. The System.Web adapters help share session and authentication between the two. Users see one application while the code moves underneath.

Rewrite the user interface

Web Forms has no direct port. Pages are rebuilt with Razor Pages, MVC or Blazor, while the business logic underneath is re-used wherever possible.

Step 3: Deal with data access and services

  • Entity Framework 6 runs on modern .NET, so you can migrate first and move to EF Core later, or move to EF Core as part of the work.
  • WCF services can move to CoreWCF to keep existing clients working, or to REST or gRPC for new ones.
  • Configuration moves from web.config to appsettings.json, environment variables and secret stores.

Step 4: Build a safety net

Before the migration, add tests around the most important workflows, even a handful of end-to-end checks. They show whether the migrated application behaves exactly like the old one.

Step 5: Plan the cut-over

Deploy to a staging environment that mirrors production, run both versions side by side where possible, and have a rollback plan. With an incremental migration, every route you move is a small, reversible release instead of one risky big bang.

Common risks

  • Old packages with no modern version, which need replacing.
  • Undocumented behaviour that users rely on. Talk to them before you start.
  • Scope creep: migration is not the moment to redesign everything. Migrate first, then improve.

We modernize .NET applications for clients, from assessment to cut-over. See our .NET modernization service, read the signs that an application needs modernizing, or ask for an assessment.