Move From .NET Framework to .NET: Step by Step

Why teams move off .NET Framework

.NET Framework is the older, Windows-only version of .NET. The last version, 4.8, still runs and gets security fixes as part of Windows. Microsoft puts new features into modern .NET, not into .NET Framework.

Moving brings real gains. Modern .NET is often faster and uses less memory. It runs on Linux and in containers, so hosting can cost less. New libraries and tools target it first.

You do not have to move in a hurry. But hiring people and finding packages for old code may get harder over time. A calm plan usually costs less than a rushed one.

Step 1: List what you have

Start with a simple inventory. For each app, write down:

• The type: website, API, Windows service, desktop app, or library
• The .NET Framework version it uses
• The packages and libraries it relies on
• The database and the systems it talks to
• How many automated tests it has
• How much the business depends on it

Then sort the list. Apps that are small, well tested, and low risk make good first moves. They teach your team the process before you touch the core system.

Step 2: Choose your path

There are three common ways to move. The table compares them.

Path	What it means	Fits when
In-place upgrade	Change the project to modern .NET and fix what breaks	The app is small or clean
Side by side	Build new parts in modern .NET and move features over a piece at a time	The app is large and must keep running
Full rewrite	Build a new app from scratch	The old code is too tangled to save

Many teams pick the side-by-side path for large systems. A reverse proxy sits in front and sends each request to the old or the new app. Over time the old app gets smaller. Microsoft's YARP is one tool that can do this job.

Full rewrites are risky. They take long, and the old app keeps changing while you build. Choose one only if you have a clear reason.

Step 3: Prepare and move the code

Prepare the shared code

Start with libraries that many apps use. Move them to a target that both worlds can read. Many teams use .NET Standard 2.0 for this, or build the library for both .NET Framework and modern .NET. Check the current documentation for the right choice for your tools.

Do these tasks early:

• Switch projects to the newer SDK-style project format
• Move package lists into the project file with PackageReference
• Update packages to versions that support modern .NET
• Replace packages that have no modern version
• Add tests around the code you plan to move

Microsoft offers the .NET Upgrade Assistant and code analyzers to find problems early. They help, but they do not do the whole job. Plan for manual work.

Move the app itself

Now pick a target version. Choose a long-term support (LTS) release, such as .NET 10. Check the current support dates before you decide.

Then work in small steps. Get the project to build. Fix the compile errors. Run the tests. Fix any change in behavior. Repeat.

Web apps need extra care. ASP.NET on .NET Framework uses a library called System.Web. ASP.NET Core does not. Startup code, settings, login, and middleware all change. Many controllers and views need only small edits.

Plan the hosting move at the same time. Modern .NET apps often run well in containers and on Linux. Our page on cloud and DevOps services covers that side of the work.

What needs extra work

Some parts of .NET Framework have no direct match in modern .NET. Look for these early, since they decide the size of the job.

• ASP.NET Web Forms: There is no direct match. Plan to rewrite those pages, for example in Razor Pages, MVC, or Blazor.
• WCF services: Server-side WCF is not part of modern .NET. Options include gRPC, REST APIs, or the community CoreWCF project.
• Entity Framework 6: It can run on modern .NET, but new work happens in EF Core. A move to EF Core may change how queries behave, so test them.
• Windows-only code: The registry, COM, and some drawing code may need replacements or a Windows host.
• AppDomains and Remoting: These are gone. Redesign the parts that use them.

Step 5: Test, release, and watch

Treat the release as part of the project. A careful release plan can lower the risk a lot.

• Compare results from the old and new app using the same data
• Run load tests, since speed and memory use will differ
• Release to a small group of users first
• Keep a way to switch back to the old app
• Watch errors and response times after each release

Automate your builds and releases so every step is repeatable. GitHub Actions and Azure DevOps both work for this.

Next step: If you want help with a plan, see our .NET development services. We usually start with a short review of your apps and a written plan before any code changes.