.NET Framework End of Life and How to Migrate

.NET Framework end of life is less a single date than a slow closing of doors. .NET Framework 4.8 is the last major version; Microsoft continues to service it as a component of Windows, but no new features ship, new libraries target modern .NET, and older 4.x versions and the Windows versions that carry them each have their own support windows. The practical answer for most organizations is to migrate to the current long-term support (LTS) release of .NET in planned increments: assess each application, fix dependencies, choose between an in-place upgrade and a strangler-fig migration, test for parity, and cut over with a rollback plan. This guide walks through each step.

• .NET Framework end of life: what is and is not ending
• Risks of staying on .NET Framework
• Migration options
• Step-by-step migration
• WebForms, WCF and Windows services
• Testing and cutover

.NET Framework end of life: what is and is not ending

There are two different lifecycles to keep apart, and most of the confusion about .NET Framework end of life comes from mixing them.

• .NET Framework (1.0 through 4.8.1) is the Windows-only framework that ships with Windows. Microsoft has stated that version 4.8 will continue to be serviced as a Windows component, with support tied to the Windows version it runs on. Earlier 4.x versions and the 3.5 line have their own end dates. Check Microsoft’s lifecycle page for the exact status of the version and operating system you run; we do not repeat dates here because they change and because articles that quote them go stale.
• Modern .NET (.NET Core 1.0 through 3.1, then .NET 5, 6, 7, 8, 9, 10 and onward) is the cross-platform successor. It ships a new major version each year. Even-numbered releases are long-term support (LTS) and odd-numbered releases are standard-term support (STS), with shorter windows. The current terms are on Microsoft’s .NET support policy page.

So “end of life” for .NET Framework does not mean your application stops working next month. It means the platform is frozen, the ecosystem has moved, and the cost of staying rises every year. For the related question of whether .NET itself is still a good bet, the short answer is yes, and our .NET development services page explains why modern .NET is our default for new business software.

Risks of staying on .NET Framework

The risk is cumulative rather than sudden. In rough order of how often they bite:

1. Unpatched dependencies. NuGet package authors drop .NET Framework targets first. A security fix in a JSON library, an authentication library or an image library may simply not exist for the version you can use.
2. Audit findings. Customer security questionnaires, SOC 2 auditors, cyber-insurance forms and HIPAA risk assessments all ask about supported platforms and patch currency. A .NET Framework application on an older Windows Server is a finding waiting to be written.
3. Hosting cost and inflexibility. .NET Framework needs Windows Server and IIS. Modern .NET runs on Linux, in containers, on Azure App Service for Linux, Container Apps, Kubernetes and serverless platforms, all of which are usually cheaper per unit of work.
4. Performance ceiling. ASP.NET Core is considerably faster than ASP.NET on .NET Framework for the same code, which often translates into fewer servers.
5. Hiring. Developers who want to work on Blazor, minimal APIs and Azure avoid WebForms and WCF jobs. Every year the pool of people willing to maintain the old stack shrinks and costs more.
6. No path to new capabilities. Blazor, gRPC, .NET Aspire, the Microsoft.Extensions.AI libraries, Semantic Kernel and the current Azure SDKs target modern .NET first or only.

Not every application needs to move now. A stable internal tool with a handful of users, no external exposure and no planned changes can stay on .NET Framework until its Windows host is retired. The point of an assessment is to sort your portfolio into “move now”, “move later” and “leave until retired”.

Migration options

There are four ways to deal with a .NET Framework application. Most portfolios use all of them.

Option	What it means	Best for	Trade-off
In-place upgrade	Convert the project to modern .NET with Microsoft’s .NET upgrade tooling, fix what breaks, keep the architecture	Class libraries, console apps, Windows services, WPF and Windows Forms, ASP.NET MVC 5 and Web API 2 with few System.Web dependencies	Everything moves at once; a long gap if the app is large
Incremental (strangler-fig) migration	A new ASP.NET Core app proxies unmigrated routes to the old one with YARP; routes move one at a time	Large ASP.NET MVC and WebForms applications that must keep shipping during the move	Two applications run side by side for a while; session and auth are shared through adapters
Targeted rewrite	Rebuild the parts with no modern equivalent (WebForms UI, WCF hosting, Workflow Foundation) while reusing business logic and the database	WebForms front ends, SOAP services with no external consumers	Design decisions reopen; scope must be frozen to finish
Replace or retire	Move to a SaaS product, merge into another system, or switch the application off	Commodity functions (helpdesk, HR forms), tools nobody uses	Data migration and change management rather than code

A fifth option people ask about, splitting the monolith into microservices during the migration, is usually a mistake because it changes architecture and platform at the same time. Migrate first, then read when a monolith-to-microservices split is worth it.

Step-by-step: how to migrate from .NET Framework to .NET Core and beyond

The platform is now just called .NET, but searches for “.NET Framework to .NET Core migration” still describe the same job. These steps apply whether the target is .NET 8, .NET 9 or the next LTS release.

1. Inventory the portfolio. List every application, service and scheduled job, its .NET version, its owner, its users, its hosting, and how often it changes. Include the ones nobody admits to running. This is the list you will prioritize.
2. Run the assessment tooling. The .NET Upgrade Assistant analyzes each project and reports API incompatibilities, package issues and project types it cannot convert. Combine it with a manual dependency review: NuGet packages without modern .NET versions, COM and native components, third-party control suites, System.Web references, AppDomains, .NET Remoting, Code Access Security and Workflow Foundation.
3. Rate effort and risk per application. A class library with no System.Web references is easy. An MVC 5 application with a clean separation of controllers, services and data access is moderate. A WebForms application with business logic in code-behind files and no tests is hard. Record the rating and the blocking dependencies next to each item in the inventory.
4. Choose an option per application. Use the table above. Sequence the easy wins first to build the pipeline, the patterns and the team’s confidence, then the applications that matter most to the business.
5. Prepare before converting. Move every project to SDK-style project files and PackageReference. Upgrade to .NET Framework 4.8 if you are below it. Retarget shared libraries to .NET Standard 2.0 so both old and new hosts can use them during the transition. Replace packages that have no modern equivalent. Introduce dependency injection and move configuration out of code. Add characterization tests around the behavior you must preserve.
6. Convert from the bottom up. Libraries first, then services, then the web host. For an ASP.NET application this is where web.config becomes appsettings.json and IConfiguration, Global.asax becomes Program.cs and middleware, HttpModules and HttpHandlers become middleware, Membership becomes ASP.NET Core Identity, and in-process Session becomes a distributed cache if you will run more than one instance.
7. Handle the hard parts separately. WebForms, WCF hosting and Windows services each get their own plan; see the next section.
8. Decide the hosting target. Staying on Windows Server with IIS is a valid first step. Azure App Service, containers on Container Apps or AKS, or another cloud are the usual destinations. Change the framework first and the platform second unless hosting is the urgent problem.
9. Test for parity, then cut over. Covered below.
10. Set the upgrade rhythm. Modern .NET expects a version upgrade every year or two. Put it in the maintenance plan now so you never face a big-bang migration again.

WebForms, WCF and Windows services

ASP.NET WebForms

WebForms does not exist in ASP.NET Core and no tool converts it. The realistic paths are a rewrite of the page layer in Blazor, whose component model, event handlers and server-side state feel familiar to WebForms developers; a rewrite in Razor Pages or MVC with a JavaScript front end; or an incremental migration where the new ASP.NET Core application sits in front and WebForms pages keep running behind the YARP proxy until each is replaced. Microsoft’s System.Web adapters share session state and authentication across the two applications so users do not notice the seam.

The main cost driver is business logic trapped in code-behind files, and the first job is usually to pull it into a class library both applications can call. Our guide to WebForms and Classic ASP modernization compares these options and how to estimate them.

WCF

Modern .NET can call WCF services through the client packages, but it cannot host them with the original server framework. The three replacements are CoreWCF, a community-maintained port supported by Microsoft that keeps your contracts and the common bindings with minimal change and suits services that external systems call over SOAP; gRPC, which fits contract-first, high-throughput service-to-service calls; and ASP.NET Core Web API with REST for browser, mobile and partner clients. The Upgrade Assistant includes a WCF-to-CoreWCF path. If a service has no external consumers, the usual choice is to fold it into the application as an in-process library and expose a REST or gRPC endpoint only where one is needed.

Windows services and scheduled jobs

These are often the easiest part. A .NET Framework Windows service becomes a .NET Worker Service that can still run as a Windows service through Microsoft.Extensions.Hosting.WindowsServices, or run as a Linux daemon, a container or an Azure Container Apps job. Scheduled tasks move to Hangfire, Quartz.NET or Azure Functions timer triggers. The migration is a good moment to add structured logging and health checks that the old service never had.

Other things that did not make the move

• Workflow Foundation: no Microsoft port; options are a community port, a workflow engine, or Azure Durable Functions.
• .NET Remoting and AppDomains: replace with gRPC or HTTP between processes and AssemblyLoadContext for plugin isolation.
• System.Drawing on Linux: use a cross-platform imaging library if the application will leave Windows.
• Reporting tools bound to .NET Framework: check each vendor’s modern .NET support before you plan; reports are a common late surprise.
• VB.NET web projects: ASP.NET Core and Razor support C# only, so VB web code is converted to C#; VB class libraries can stay in VB.

Testing and cutover

A migration that changes nothing visible to users has one test: does it behave the same. Build the parity suite before you convert anything.

• Characterization tests that capture current behavior, including the odd corners nobody documented. Record real requests and responses where you can.
• API contract tests for every endpoint external systems call, run against old and new.
• Data comparison: run the same batch job or report on both versions and diff the output.
• Performance baseline on the old application so you can prove the new one is not slower, and usually show that it is faster.
• Security scan of the new application and its dependencies before it faces the internet.

Cutover for an in-place upgrade is a deployment with a rollback: the old version stays deployable, traffic switches in stages where the platform allows it, and monitoring watches error rates and latency on both sides. Cutover for a strangler-fig migration is gradual by design; the last step is removing the final proxied route and switching off the legacy application. Either way, keep the old environment available for a defined period after the switch, then decommission it deliberately so it does not become the next forgotten system.

Where PS3G fits

PS3G runs assessment-first .NET migration and modernization projects for organizations of every size: the Upgrade Assistant and dependency analysis, a per-application report with effort and risk, in-place or strangler-fig migration, parity testing by our testing center of excellence, and cutover to your current hosting or to Azure. After the migration, the same team provides ongoing .NET development under a fixed-scope, dedicated-team or managed-services arrangement. We work from Wilmington, Delaware and an India delivery center, and we have spent more than ten years on the Microsoft stack. If you are choosing a partner, our guide to choosing a .NET development company lists the questions to ask us and anyone else.

Related reading

• ASP.NET WebForms and Classic ASP Modernization: Your Realistic Options
• How to Choose a .NET Development Company: 12 Questions to Ask
• Monolith to Microservices: When It’s Worth It and How to Do It

Frequently asked questions

Is .NET Framework 4.8 still supported?

Microsoft has said .NET Framework 4.8 will continue to be serviced as a component of the Windows versions that include it, so it receives security fixes for as long as that Windows version is supported. It does not receive new features. Earlier 4.x versions have separate end dates. Confirm your exact version and operating system on Microsoft’s lifecycle page rather than relying on a date from an article.

Is .NET Core the same as .NET 8 and .NET 9?

Yes, in lineage. .NET Core 1.0 through 3.1 were the first cross-platform releases; Microsoft dropped the word Core with .NET 5 and the platform has been called .NET since. When people search for migrating to .NET Core today, they mean the current releases, .NET 8, .NET 9 and whatever is current when you read this. Target the latest long-term support release unless you have a specific reason not to.

Can I convert a .NET Framework project automatically?

Partly. Microsoft’s .NET upgrade tooling converts project files, updates package references and applies many code fixes automatically, and works well for class libraries, console applications, Windows services, WPF and Windows Forms. It cannot convert WebForms pages or WCF service hosting, and it does not fix design problems such as business logic in code-behind. Expect it to do the mechanical part and to leave the judgment to people.

Do we need to move to Azure when we migrate?

No. Modern .NET runs on Windows Server with IIS, so you can upgrade the framework and keep your hosting. Many organizations do exactly that, then decide about Azure, AWS or Google Cloud as a separate step with better information. Doing the two changes separately keeps the variables apart when something breaks and makes the rollback plan simpler.

What is the biggest hidden cost in a .NET migration?

Usually the things nobody wrote down: business rules buried in WebForms code-behind, a reporting tool or control suite with no modern .NET version, an undocumented integration that only works because of an old authentication mode, and the absence of tests to prove the new version matches the old. A thorough assessment finds most of these before they become schedule surprises.