.NET Framework to .NET Core: Should You Move Now?

If your business runs on an application built with .NET Framework, you do not need to panic, but you do need a plan. Microsoft has said .NET Framework 4.8 is the last major version. It will keep receiving security fixes and stays supported as part of Windows, yet new features, performance work and new platforms are all going into .NET Core. .NET 5, due in November 2020, continues that line and drops the word “Core” from the name.

So the real question is not whether your app should eventually move, but when, and how much of it. For many teams the answer in mid-2020 is: start preparing now, migrate the parts that port cleanly to .NET Core 3.1, and plan the rest around .NET 5 and beyond.

Where things stand in June 2020

A quick summary of the current picture:

.NET Framework 4.8 (released April 2019) is the final major release of .NET Framework. It is Windows only.
.NET Core 3.1 (released December 2019) is a long-term support (LTS) release, supported for three years from release. It runs on Windows, Linux and macOS.
.NET Core 2.1 is also LTS but older, with support ending in August 2021. .NET Core 2.2 is already out of support.
.NET 5 was announced in May 2019 as the next version of .NET Core, with previews available now and a planned release in November 2020. Microsoft has said it will not be an LTS release.
Blazor WebAssembly shipped in May 2020, giving .NET teams a way to build browser front ends in C#.

Why companies are moving

Performance. ASP.NET Core was rebuilt from the ground up and is faster and lighter than classic ASP.NET on the same hardware. For busy APIs and web apps that can mean fewer servers or smaller cloud instances.

Linux and containers. .NET Core apps run on Linux and fit well in Docker containers. That opens up cheaper hosting, Kubernetes and the same deployment tools your other teams may already use.

Side-by-side versions. Each .NET Core app can carry its own runtime version. Updating one app no longer risks breaking every other app on the server, which was a common fear with machine-wide .NET Framework updates.

Modern tooling. The SDK-style project files, the dotnet command line and built-in dependency injection make projects simpler to build, test and automate.

Hiring and the future. New libraries, samples and training target .NET Core first. Developers increasingly expect to work on it.

What ports easily and what does not

This is where migrations succeed or stall. Some parts of .NET Framework have direct equivalents in .NET Core. Others do not exist there and will not be added.

Usually straightforward

Class libraries with business logic and little dependence on Windows-specific APIs. Retargeting them to .NET Standard 2.0 lets the same library work in both your old Framework app and new Core code during the transition.
ASP.NET MVC and Web API apps. The concepts carry over to ASP.NET Core MVC, though startup, configuration, routing and dependency injection change. Expect real code changes, not just a recompile.
Console apps and Windows services, which can move to the .NET Core generic host and worker services.
Entity Framework 6 code. EF 6.3 and later run on .NET Core 3.x, so you can move the app first and decide on Entity Framework Core later.

Needs a rewrite or a different approach

ASP.NET Web Forms. Not available on .NET Core and not coming. Options are rewriting pages in ASP.NET Core MVC or Razor Pages, or in Blazor, which Microsoft suggests as the closest fit for Web Forms developers because of its component model.
WCF services. The WCF client libraries exist for .NET Core, but hosting WCF services does not. Microsoft points teams to gRPC or ASP.NET Core Web API instead. CoreWCF, a community project, is working on a port of the server side, but it is not yet a production option for most businesses.
Windows Workflow Foundation. Not ported. Workflows need redesigning with another engine or plain code.
Code that depends on System.Web, such as HttpContext.Current, session state handling and HTTP modules. ASP.NET Core has its own request pipeline and middleware model.
AppDomains, .NET Remoting and Code Access Security. Not supported on .NET Core.

Desktop apps

Windows Forms and WPF apps can run on .NET Core 3.x, but only on Windows. The Windows Forms designer support in Visual Studio is still catching up, so check your tooling before you commit. Moving a desktop app gets you side-by-side deployment and newer runtime features, not cross-platform support.

How to decide: move, wait or leave it

Use these questions to place each application.

Move now if: – It is an ASP.NET MVC or Web API app under active development. – You want Linux hosting, containers or a lower cloud bill. – Performance or scaling is a current problem. – Most dependencies (NuGet packages, internal libraries) already support .NET Standard or .NET Core.

Prepare now, move with .NET 5 or later if: – The app depends on WCF hosting, Web Forms or Workflow and needs partial redesign anyway. – Your team is new to ASP.NET Core and you want time to learn on smaller projects first. – You need the next LTS release for policy reasons. .NET 6, planned for November 2021, is expected to be the next LTS after 3.1.

Leave it on .NET Framework if: – It is stable, rarely changed and does its job. – It has a planned retirement or replacement date. – The migration cost is higher than any benefit you can name.

.NET Framework 4.8 is not going away soon. A stable internal tool that nobody touches can stay where it is for years. Spend the migration budget where it buys speed, lower costs or easier change.

A practical migration plan

Inventory. List every application, its project types, target framework, NuGet packages and Windows-specific dependencies.
Run the .NET Portability Analyzer. It reports which APIs your assemblies use that are not available on .NET Core, so you see the gaps before writing code.
Upgrade to .NET Framework 4.7.2 or 4.8 first. This gives the best compatibility with .NET Standard 2.0 libraries.
Convert to SDK-style project files. The try-convert tool from Microsoft can help with this step.
Move shared libraries to .NET Standard 2.0. Now both the old app and new .NET Core code can use them.
Check package support. Replace or upgrade packages that do not support .NET Core.
Migrate the host application. For web apps, create a new ASP.NET Core project and bring controllers, views and services across, rewriting startup, configuration and authentication.
Strangle the old app gradually where it makes sense. For large systems, put new ASP.NET Core services alongside the old app and route traffic to them one area at a time, rather than attempting a big-bang rewrite.
Test thoroughly. Automated tests around business rules pay for themselves here. If you do not have them, write them for the most important paths before you migrate.
Plan the hosting change. Linux, containers and Azure App Service on Linux are options now, but you can stay on Windows and IIS if that suits your operations team.

Common pitfalls

Treating it as a recompile. Web apps especially need real changes. Budget for them.
Ignoring configuration. web.config settings move to appsettings.json and environment variables. Secrets need a proper home.
Authentication surprises. Forms authentication and Windows authentication work differently in ASP.NET Core. Plan this early.
Third-party controls. Older UI component suites may not have .NET Core versions. Check with the vendor.
Doing everything at once. Changing framework, database, hosting and front end in one release makes problems hard to trace.

FAQ

Will Microsoft stop supporting .NET Framework?

Not in the near term. .NET Framework 4.8 stays supported with Windows and will receive security and reliability fixes. It will not receive major new features.

Should we target .NET Core 3.1 or wait for .NET 5?

If you are ready, 3.1 is LTS and a good target today. Code that runs on 3.1 should move to .NET 5 with relatively small changes.

Can we keep using Entity Framework 6?

Yes. EF 6.3 and later run on .NET Core 3.x. You can migrate to Entity Framework Core later as a separate step.

Is Blazor ready for business apps?

Blazor Server has been supported since .NET Core 3.0, and Blazor WebAssembly shipped in May 2020. It suits internal and line-of-business apps well, especially for teams strong in C#.

Need help planning a migration?

We help businesses assess older .NET applications, decide what to move and when, and carry out migrations without stopping day-to-day operations. See how we approach .NET and custom builds at IWS custom development.