Moving Off .NET Framework (and .NET 8): A Migration Checklist for Small Teams

First, which .NET are you on?

"We're on .NET" can mean two very different things, and the deadline only applies to one of them.

Microsoft announced that .NET 8 (a long-term support release) and .NET 9 (a standard-term release) both end support on November 10, 2026, and recommends moving to .NET 10, which is supported until November 2028 (.NET Blog, June 2026). After that date there are no more security patches.

.NET Framework is different. Versions 4.8 and 4.8.1 are treated as part of Windows and stay supported as long as the Windows version they run on is supported. Versions 4.5.2 through 4.6.1 reached end of support on April 26, 2022 (Microsoft .NET Framework support policy). So a .NET Framework 4.8 application isn't facing a hard deadline. The problem is that it can't use anything new, libraries are dropping support for it, and fewer developers want to work on it every year.

To check a project, open its .csproj file. <TargetFramework>net8.0</TargetFramework> means .NET 8. <TargetFrameworkVersion>v4.8</TargetFrameworkVersion> means .NET Framework 4.8.

If you're on .NET 8 or 9: upgrade to .NET 10 now

This is usually the easy case. Moving between modern .NET versions is mostly routine:

1. Change the target framework to net10.0 in each project, and update the SDK version in global.json if you have one.
2. Update NuGet packages, starting with Microsoft's own packages (ASP.NET Core, Entity Framework Core) to their version 10 releases.
3. Read Microsoft's breaking-change list for each version you are crossing and search your code for the affected APIs.
4. Update build agents, Docker base images and hosting (Azure App Service, IIS hosting bundle) to the .NET 10 runtime.
5. Run your tests, deploy to a staging environment, and watch logs closely after the production release.

For a small, well-kept application this can be a matter of days. If it turns out to be harder, that is a sign of deeper problems worth knowing about.

If you're on .NET Framework: modernize in stages

Moving from .NET Framework to modern .NET is a real project, not a version bump. Don't plan it as one big rewrite. Plan it as a sequence of releases that each leave the application working.

1. Take inventory

• List every project in the solution and what kind it is: web, Windows service, class library, desktop.
• List every NuGet package and third-party DLL, and check whether each has a modern .NET version.
• Find the hard blockers. The big ones are ASP.NET Web Forms (not available in modern .NET), WCF services (the server side lives on in the community-run CoreWCF project), and heavy use of System.Web.
• Note anything Windows-specific: the registry, COM components, Windows authentication.

2. Build a safety net first

• Put automated tests around the parts of the application that change most and matter most. Even a handful of end-to-end tests on key screens is worth it.
• Make deploys repeatable. If releasing today is a manual, late-night process, fix that before migrating anything.

3. Move the shared code first

Class libraries with business logic are usually the easiest to move. Retarget them to .NET Standard 2.0 or multi-target them, so both the old application and new code can use them during the transition.

4. Move the application in slices

• ASP.NET MVC and Web API projects move to ASP.NET Core with a reasonable amount of work, since the concepts carry over.
• Web Forms pages need rebuilding, usually in ASP.NET Core with Razor Pages or Blazor. Rebuild one area at a time and route traffic to the new version as each area is ready, so both run side by side.
• Windows services generally become .NET worker services.
• Data access on Entity Framework 6 can stay on EF6 for a while (it runs on modern .NET) before moving to EF Core later.

5. Use tooling, but check its work

Microsoft has deprecated its .NET Upgrade Assistant and now points developers to an AI-based tool, GitHub Copilot app modernization, which requires a paid Copilot subscription (GAPVelocity, February 2026). Tools like this are good at the mechanical parts of an upgrade. Treat their output the way you would treat a junior developer's pull request: useful, and in need of review and testing.

6. Release, measure, repeat

Each slice goes to production on its own, with monitoring. Because you are always running a working system, you can pause the migration whenever the business needs the team for something else, and you can stop altogether once the parts that matter are modern.

What it costs

A .NET 8 to .NET 10 upgrade on a small application is often a few days of senior time. A .NET Framework migration depends on the size of the application and how many hard blockers it has, which is why the first step should be an assessment that breaks the work into stages with a price for each. You can fund it one stage at a time.

We do this work at $100 to $125 an hour, or as fixed-price stages once the assessment is done. Read more on our legacy modernization page.

Sources

• .NET 8 and .NET 9 end of support, .NET Blog, Microsoft, June 29, 2026
• .NET Framework support policy, Microsoft, accessed October 2026
• What happened to the .NET Upgrade Assistant?, GAPVelocity, February 14, 2026