Quick answer: .NET 5 released in November 2020 as the next step after .NET Core 3.1. It is not an LTS release, but it is the current destination for new cross-platform .NET work. Many .NET Framework apps can move in stages: inventory dependencies, port libraries first, move web or API layers to ASP.NET Core on .NET 5, and leave Windows-only pieces for later. Apps that rely heavily on Web Forms, WCF server, or Windows-only APIs may need a longer plan than a straight upgrade.
Where things stand in January 2021
A short status check helps before you open a migration ticket.
- .NET Framework 4.8 remains the last major Framework release. It stays supported on Windows with security fixes, but new platform work is not going there.
- .NET Core 3.1 is still the current LTS line, supported for three years from its December 2019 release.
- .NET 5.0 shipped 10 November 2020. Microsoft positioned it as a Current (not LTS) release, with .NET 6 planned as the next LTS later. For teams writing now, .NET 5 is the release you target for new ports unless you must stay on an LTS runtime for policy reasons.
- The product name dropped “Core.” Going forward, “.NET 5” means the unified, cross-platform stack that grew out of .NET Core.
If you read our earlier piece on moving from .NET Framework to .NET Core, the decision framework is the same. The difference in January 2021 is that .NET 5 is no longer a preview. You can ship against it.
Why move at all
Not every Framework app needs to move this quarter. The ones that benefit most usually need at least one of these:
Performance and density. ASP.NET Core on .NET 5 handles more requests per server than classic ASP.NET on Framework for typical APIs and MVC-style apps. That can cut hosting cost or free headroom during peaks.
Linux and containers. .NET 5 runs on Windows, Linux and macOS. If your ops team wants Docker and Kubernetes, Framework on IIS is a poor fit. Container-friendly apps are easier to scale and redeploy.
Side-by-side runtimes. Each app can bring its own .NET 5 runtime. You avoid the old fear that updating a machine-wide Framework version would break every site on the box.
Modern libraries and hiring. New samples, NuGet packages and training target the .NET 5 line first. Teams that stay only on Framework eventually struggle to hire and to keep dependencies current.
For greenfield work, the comparison with other stacks is also clearer than it was a few years ago. Our overview of .NET vs Node.js still applies when you are choosing a platform, not only when you are migrating one.
What ports cleanly, and what does not
Treat this as a triage list, not a promise that every project is easy.
Usually straightforward
- Class libraries that already target .NET Standard 2.0
- ASP.NET Core 3.1 apps upgrading to .NET 5 (project file and package updates)
- Console tools, worker services and most test projects
- Entity Framework Core based data access (watch package versions)
- REST APIs built in a style close to ASP.NET Core Web API
If you already build HTTP APIs, our guide to ASP.NET Core Web API is a useful target shape for Framework Web API or older MVC JSON endpoints.
Needs planning
- ASP.NET MVC 5 on System.Web (controllers and views move, but project structure and middleware differ)
- Entity Framework 6 (EF Core is a different product; some features and providers do not map one-to-one)
- WCF clients (often replaceable with gRPC, REST or remaining WCF client libraries; WCF server hosting is a bigger gap)
- Apps with many Framework-only NuGet packages that have no .NET 5 build yet
Hard or out of scope without a rewrite
- Web Forms. There is no Web Forms on .NET 5. Plan a UI rewrite (MVC, Razor Pages, Blazor or a separate front end) if you must leave Framework.
- Windows-only APIs such as AppDomains, remoting, or deep System.Drawing usage on non-Windows hosts. Some packages have alternatives; some do not.
- Classic ASP leftovers. Those need a separate path. See classic ASP migration.
Be honest in the inventory. A “migration” that secretly includes a full UI rewrite is a product project, not a weekend upgrade.
A practical migration path
1. Inventory the solution
List every project, its target framework, and its NuGet references. Note System.Web usage, WCF endpoints, Windows services and any COM or GAC dependencies. Run the .NET Portability Analyzer or try retargeting a library to netstandard2.0 or net5.0 in a branch to surface missing APIs early.
2. Move shared libraries first
Port class libraries before the web host. Multi-target (net48 and net5.0) if you must keep the old app running while new code lands. Shared libraries with clean boundaries make the later host cutover much smaller.
3. Introduce ASP.NET Core beside the old site if needed
For large apps, a strangler approach works well: new endpoints on ASP.NET Core (.NET 5), old pages still on Framework, routed by reverse proxy or IIS. Migrate feature by feature instead of a big-bang cutover.
4. Replace Framework-only features deliberately
- Authentication and session: move to ASP.NET Core equivalents rather than copying System.Web patterns.
- HTTP modules and handlers: become middleware.
- Static files, compression and HTTPS redirection: use the built-in middleware pipeline.
- Background work: consider worker services instead of ad-hoc threads in the web process.
5. Bring tests with you
Do not migrate without automated coverage on the critical paths. If the Framework app has almost no tests, write characterization tests around the APIs you will move first. Our overview of unit testing in .NET is a practical starting point for teams that never invested in tests.
6. Watch data access and SQL Server
EF6 to EF Core is a migration of its own. Confirm provider support, migrations strategy and query behavior under load. Slow queries will still dominate response time after a successful platform move. Tuning advice in SQL Server performance for .NET apps remains relevant on .NET 5.
7. Decide what stays on Framework for now
Some Windows services, internal admin tools or Web Forms modules can stay on Framework 4.8 while customer-facing APIs move. Document that boundary so nobody assumes “we are on .NET 5” when half the estate is not.
.NET 5 specifics worth knowing for a migration
Single file and trimmed publishes. Useful for tools and some services. Test carefully; trimming can remove code that reflection still needs.
C# 9. New language features are available on .NET 5. You do not have to adopt them on day one. Prefer a boring port first, then modernize.
gRPC and real-time options. If you are replacing chatty WCF or building push features, evaluate gRPC and SignalR on ASP.NET Core as part of the target design, not as afterthoughts.
Support policy. .NET 5 is Current, not LTS. Plan an upgrade path toward the next LTS when your organization requires long support windows. That is a calendar item, not a reason to stay on Framework forever.
Project file and package tips
SDK-style projects are the default on .NET 5. Expect csproj files that are short and readable compared with old non-SDK projects. Update:
TargetFrameworktonet5.0(ornet5.0-windowswhen you truly need Windows-specific APIs)- Microsoft.AspNetCore.* and EF Core packages to versions aligned with .NET 5
- Test SDK and analyzer packages so CI builds cleanly
Run the app under the same hosting model you will use in production (Kestrel behind IIS or nginx, or a container) before you call the migration done. Differences in hosting, not C#, cause many late surprises.
Common questions
Should we wait for the next LTS instead of .NET 5?
If policy forces LTS-only runtimes, staying on .NET Core 3.1 until the next LTS is defensible. If you can run Current releases, .NET 5 is the better migration target today because it is what new libraries and docs assume. Either way, start the inventory now. Waiting does not shrink Web Forms or WCF work.
Can we just retarget the Framework csproj to net5.0?
Sometimes for simple libraries. For System.Web apps, no. You need an ASP.NET Core project model and a middleware-based pipeline. Treat it as a port, not a checkbox in project properties.
What about desktop apps?
.NET 5 supports Windows desktop (WinForms and WPF) with the Windows targeting pack. That is a separate track from web migration. Do not mix desktop and web cutovers in one unscoped project.
Is .NET Framework unsafe after .NET 5?
No. Framework 4.8 still receives security updates. The risk is stagnation: fewer new packages, harder hiring and a growing gap with the rest of the .NET ecosystem.
The bottom line
A .NET 5 migration is most successful when you inventory honestly, port libraries first, move web and API layers to ASP.NET Core in stages, and leave true Windows-only or Web Forms pieces on a deliberate timeline. .NET 5 is available now. The work is engineering and product planning, not a single install wizard.
If you want help scoping a Framework-to-.NET 5 move for a business app, see how our custom development services work.
