.NET Framework to Modern .NET Migration

.NET Framework 4.8.x still receives security fixes as part of Windows, but it gets no new features, runs only on Windows and is not where Microsoft's performance work happens. Modern .NET runs on Linux and in containers, is markedly faster for typical web workloads, and is what new libraries and Azure services target.

Staying put also has a hiring cost: fewer engineers want to work on WebForms and WCF every year, and the ones who do are expensive.

Some .NET Framework technologies have no direct equivalent: ASP.NET WebForms (moved to Blazor or Razor Pages), WCF server hosting (moved to gRPC or REST, or kept with the community CoreWCF project), and AppDomains and .NET Remoting (redesigned). We identify these in the assessment so they are planned, not discovered mid-project.

Most business logic, data access and class libraries port with modest change - which is why a staged migration usually costs far less than a rewrite.

We always target the latest stable .NET release - currently .NET 10, a long-term-support version. If you are already on an older release of modern .NET that is out of support or close to it, the same playbook applies - and the jump is much smaller than from .NET Framework.

Beyond WebForms and WCF, the assessment flags the quieter breaking changes. System.Web and HttpContext.Current do not exist in ASP.NET Core, so code that reaches for the current request from deep inside business logic has to receive it explicitly. Global.asax, HTTP modules and handlers become middleware; web.config settings and ConfigurationManager calls move to appsettings files, environment variables and the options pattern.

Other common items are BinaryFormatter, which is disabled in modern .NET; System.Drawing, which is Windows-only; Windows registry, COM and Windows identity calls that will not work in a Linux container; and Entity Framework 6 queries that behave differently in EF Core, where lazy loading is off unless you opt in.

For web applications we follow Microsoft's documented incremental approach. A new ASP.NET Core application is placed in front of the existing one, and YARP, Microsoft's reverse proxy library, forwards every route that has not been migrated yet to the old .NET Framework site. Users see one application while pages and endpoints move across one at a time.

The System.Web adapters let both applications share session state and sign-in during the transition, so a user moving between old and new pages stays logged in. When the proxy is no longer forwarding any traffic, the old application is switched off.

Before code moves, we write characterisation tests that record what the application does today, including the odd behaviour users rely on. During the migration the same HTTP-level tests run against the old and new versions and compare responses, contract tests protect clients of replaced WCF services, and performance baselines catch regressions. Our developers use AI tools to draft these tests in bulk, then review and correct each one against the real behaviour.

Modern .NET runs on its own Kestrel web server, so IIS becomes optional: it can still host the app, or the app can run in Linux containers behind a load balancer or ingress. Moving off Windows changes a few habits - file paths become case-sensitive, logs go to standard output for the platform to collect, configuration and secrets come from environment variables or a vault, and data protection keys must be stored centrally so sign-ins survive restarts and scale-out.

Windows authentication is usually replaced with OpenID Connect against Microsoft Entra ID or your identity provider. We add health checks and a CI/CD pipeline that builds the container image, so each release is repeatable and easy to roll back.