Software Movers
← All guides

How do I modernize a .NET Framework app in 2026?

By Software Movers — last updated 2026-04-21

The short answer

Modernize a .NET Framework app in 2026 by porting it piece-by-piece to .NET 8 or .NET 9, not by rewriting it. Start with a dependency inventory, upgrade to the .NET Upgrade Assistant, move shared libraries first, and keep both the old and new app running behind the same URL until parity is proven.

Why you are here

.NET Framework 4.8.1 is the final version Microsoft will ship. It is still supported for the lifetime of the Windows version it ships with, but it will not get new features, and the ecosystem has moved on. If you are still on 4.6 or 4.7.2, you are three LTS releases behind the supported line, and most NuGet packages you rely on have either stopped updating or have moved to target .NET 8+ only.

Two out of three software projects go over budget, with an average overrun of 45% (industry scope-creep data cited across the modernization research). Rewrites are the worst offenders. The way to stay out of that number is to plan the modernization as a port, not a rebuild.

The 8-step port that actually works

1. Inventory before you touch anything

List every project in the solution, every NuGet package, every third-party DLL (especially the ones you do not have source for), every database your app talks to, every Windows-specific API call (System.Web, WCF, Remoting, AppDomain). Flag anything that has no .NET 8 equivalent — those are the hard parts.

2. Run the .NET Upgrade Assistant

Microsoft ships a free CLI tool (dotnet tool install -g upgrade-assistant) that reads a Framework project and produces a best-effort .NET 8 version plus a report of what it could not translate. It will not finish the job. It will tell you, in minutes, how big the job actually is.

3. Move shared class libraries first

Class libraries with no System.Web dependency usually port cleanly to .NET Standard 2.0, which both Framework and modern .NET can consume. This lets your Framework app keep running while the libraries get tested on the new runtime.

4. Replace ASP.NET Web Forms with ASP.NET Core MVC or Razor Pages

Web Forms has no forward path. There is no "upgrade Web Forms to Core." You port the screens. This is the step where most modernizations stall, and it is where you most need an approach that treats your existing screens as the blueprint instead of a thing to discard. We wrote more about that in how to export a Bubble app to real code — different platform, same "translate, do not rewrite" rule.

5. Replace WCF with gRPC or HTTP+JSON

WCF is not coming to .NET 8. CoreWCF exists and handles the most common bindings, but for new code, gRPC or a plain REST API is the standard. Pick based on whether the caller is also under your control.

6. Update Entity Framework

EF 6 runs on .NET 8 but is on maintenance-only. EF Core 8 is the path forward. The migration is not automatic — query syntax differs, change-tracking behaves differently, and some patterns (lazy loading, DbContext pooling) need to be rethought. Plan a week per complex context.

7. Run both apps behind the same URL (the strangler fig)

Put a reverse proxy (YARP, nginx, or your existing load balancer) in front. Route new endpoints to the .NET 8 app, legacy endpoints to Framework. Move endpoints over one at a time. Users do not notice. You ship continuously instead of for six months in a branch.

8. Cut the Framework app last, not first

The moment you delete the old app is the moment you discover a feature nobody remembered. Keep it deployable for at least 90 days after parity. This is the single biggest regret we hear on calls.

A timeline that is not a lie

For a typical 200k-line .NET Framework 4.7 business app with EF 6 and a handful of WCF services:

| Phase | Duration | What ships | |---|---|---| | Inventory + Upgrade Assistant | 1-2 weeks | Written report, effort estimate | | Shared library port | 3-4 weeks | .NET Standard class libs green in both runtimes | | First Core MVC page behind proxy | 2-3 weeks | One real screen live on .NET 8 | | Port remaining screens | 3-6 months | Depends on screen count and Web Forms controls | | WCF → gRPC | 1-2 months | Parallel to screen work | | EF 6 → EF Core 8 | 1-2 months | Parallel | | Cutover + 90-day soak | 3-4 months | Framework app stays warm |

Anyone promising "six weeks flat" for a real business app is selling a rewrite disguised as a port. Ask for the inventory first.

What this actually costs

A US-based senior .NET developer loaded cost is roughly $160-200k/year in 2026. A modernization like the one above is 6-12 months of focused work for one senior developer, or 3-6 months for a small team. That is $80-200k in labor alone — before you add up the hidden costs: QA, deployment infra, the security review that surfaces three CVEs in your old NuGet packages.

If you are deciding whether to staff this or outsource it, the related reading is should a small business hire a dev shop or a retainer.

What would make this guide wrong

  1. Microsoft changes its support stance. If .NET Framework 4.8.1 gets a surprise LTS extension past 2030, the urgency changes. As of April 2026, the commitment tracks the host Windows version and there is no new Framework version planned.
  2. Your app is a ClickOnce Windows Forms desktop, not a web app. Most of this guide is web-shaped. WinForms and WPF have their own .NET 8 story (both are supported; Windows-only). The strangler-fig pattern does not apply.
  3. The app is under 20k lines and has no third-party DLLs. At that size, a true rewrite on .NET 8 can ship in 4-6 weeks and will be cleaner. Rewrites are only wrong at scale.

Changed since last time

  • 2026-04-21 — First published.

Sources

If you want a flat-monthly partner to host the ported app and run the pipeline around it — CI/CD, preview environments, flags, monitoring, rollback, on-call — see pricing or start with a $299 legacy audit to map the port first.

Move My Software →
How do I modernize a .NET Framework app in 2026? — Software Movers