INSIGHTS / .NET
Moving from .NET Framework to .NET 10: a practical playbook.
How to move business-critical .NET Framework applications to .NET 10 incrementally: assessing compatibility, handling WCF, Web Forms and System.Web dependencies, and migrating safely with the strangler-fig pattern.
Why move, and why now
.NET Framework 4.8.x remains supported as part of Windows, but it receives no new features, and much of the modern ecosystem — libraries, cloud SDKs, performance improvements and container hosting — targets modern .NET. .NET 10 is a long-term-support release, giving a stable, supported target for the next several years.
Assess before estimating
Estimates based on line counts are unreliable. Analyse what the code actually depends on.
- Run the .NET Upgrade Assistant and API compatibility analysis across every project
- Inventory NuGet dependencies and check each for a modern .NET version or replacement
- Identify Windows-specific APIs (registry, COM, GDI+) that affect hosting choices
- Map shared libraries — converting them to .NET Standard 2.0 or multi-targeting often unblocks everything else
Handle the hard dependencies
A few technologies cause most of the effort, and each has a known path.
- WCF services: CoreWCF for server compatibility, or replacement with gRPC or HTTP APIs; client proxies via the modern WCF client packages
- ASP.NET Web Forms: no direct port — rebuild incrementally in Blazor or Razor Pages behind a strangler proxy
- System.Web and HttpContext dependencies: isolate behind abstractions, or use the System.Web adapters to share code during the transition
- Entity Framework 6: run EF6 on modern .NET first, then migrate to EF Core where it adds value
Migrate incrementally with a strangler proxy
Put a YARP reverse proxy in front of the existing application. Route new or migrated endpoints to the .NET 10 application and everything else to the original. Shared authentication and session state are bridged during the transition. Users see one application while functionality moves piece by piece, and every step can be rolled back by changing a route.
Make it safe to change
Before moving code, add characterisation tests around critical behaviour, capture performance baselines, and set up CI that builds and tests both applications. After each slice moves, compare behaviour and latency against the baseline before retiring the old path.
Hosting the result
Modern .NET opens up Linux hosting, containers and serverless options. Azure App Service remains the simplest home for most web applications; Container Apps suits containerised services; Azure Functions with the isolated worker suits event-driven workloads.
Contact: contact@nexaarislabs.com