How to Migrate From .NET Framework to .NET 8
Quick answer: Migrate in four moves. Assess which components depend on framework-only APIs, port the plain class libraries to .NET 8 (most need little change), replace the framework-only pieces (old ASP.NET, WCF, WebForms) with their ASP.NET Core equivalents, and cut over incrementally behind a compatibility layer so the app keeps running throughout. Target the current LTS release.
.NET Framework is not getting new features, and each year on an unsupported version adds security and hiring cost. See the true cost of legacy .NET Framework. The good news: modern .NET is a genuine continuation, and most of a typical codebase ports more easily than teams expect.
Step 1: Assess what actually blocks you
Run the .NET Upgrade Assistant and the API portability analyzer across the solution. What you are looking for is the split between:
- Portable code. Class libraries with business logic, data models, and algorithms. These usually move with minor changes to project files and a few package swaps.
- Framework-only code. Anything on
System.Web, WebForms, classic WCF hosting,AppDomain, MSMQ, or Windows-specific APIs. These need real replacements, and they define the size of the project.
The ratio between those two is your estimate.
Step 2: Port the class libraries
Convert project files to the SDK style, retarget to .NET 8, and replace packages that changed names or split apart. Compile, fix what breaks (usually a handful of API moves), and get the existing unit tests green. Do this for the leaf libraries first and work up the dependency graph. At this stage nothing is deployed; you are proving the core logic runs on modern .NET.
Step 3: Replace the framework-only pieces
| .NET Framework | Modern .NET replacement |
|---|---|
| ASP.NET MVC 5 | ASP.NET Core MVC |
| ASP.NET Web API 2 | ASP.NET Core Web API |
| WCF service host | ASP.NET Core Web API or gRPC |
| WebForms | ASP.NET Core MVC, Razor Pages, or Blazor |
System.Web (session, config, HttpContext) | ASP.NET Core equivalents, IHttpContextAccessor, options pattern |
web.config | appsettings.json plus environment configuration |
Windows services / TopShelf | IHostedService in a generic host |
This is where the design work is. WebForms in particular has no mechanical path, so budget for it.
Step 4: Cut over incrementally
Do not flip the whole app at once. Options, roughly in order of preference:
- Strangler pattern. Stand up the .NET 8 app alongside the old one and route endpoints or features across one at a time, so traffic shifts gradually and rollback is per-feature.
- Compatibility layer. Keep the legacy frontend running against a new .NET 8 service layer during the transition, then retire the old host once parity is proven.
- Parallel run. Send the same requests to both stacks and compare outputs before switching, for high-risk paths.
The database follows its own track. See database migration strategies.
The takeaway
A .NET Framework to .NET 8 migration is an assessment, a port of the portable code, targeted replacement of the framework-only pieces, and an incremental cutover. Sized by how much of the app is welded to System.Web, not by total lines of code.
If you want an assessment that tells you the real size of the project, Eximo runs a two-week modernization sprint.
Frequently asked questions
Can you migrate from .NET Framework to .NET 8 without a full rewrite?
Usually yes. Most business logic in class libraries ports with few changes. The work concentrates in framework-only components (old ASP.NET, WCF, WebForms, System.Web dependencies) which need replacements. A phased migration behind a compatibility layer avoids a big-bang rewrite.
What replaces WCF and ASP.NET in .NET 8?
WCF services typically move to ASP.NET Core Web API or gRPC. WebForms has no direct successor; those apps move to ASP.NET Core MVC, Razor Pages, or Blazor. Classic ASP.NET MVC maps fairly directly onto ASP.NET Core MVC.
How long does a .NET Framework to .NET 8 migration take?
It depends on how much of the app touches framework-only APIs. A service-heavy backend with clean class libraries can move in weeks. An app built on WebForms with deep System.Web coupling is a larger project measured in months, best done in phases.
Should you target .NET 8 or wait for a newer version?
Target the current Long-Term Support release. .NET 8 is LTS with three years of support. Moving to LTS now and stepping to the next LTS later is lower risk than staying on unsupported .NET Framework while you wait.
Building something like this?
Eximo builds AI ingestion pipelines, multi-agent systems, and production RAG for regulated and restricted environments. Tell us what you're working on.
Schedule a consultation