.NET ModernizationEvery stack on this list, shipped in production
Legacy .NET is not one problem. A WebForms app, a WCF service layer and a WinForms client each stall for entirely different reasons, and an estimate is only as good as whoever has actually lived in that stack. We have written production code in all of them — including the VB.NET ones nobody wants to open — so the assessment is recall rather than a research phase you pay for.
2002 – 2012ASP.NET WebForms↳ASP.NET Core with Razor Pages or Blazor
The page lifecycle, ViewState and server controls have no equivalent, so the markup genuinely is rewritten. The business logic underneath it usually is not — and pulling the two apart is most of the job.
2003 – 2010ASMX and WCF services↳ASP.NET Core APIs, gRPC, or CoreWCF
Bindings, behaviours and SOAP contracts do not port. Where the callers are third parties you cannot change, CoreWCF keeps the contract alive while everything behind it moves.
2007 – 2015Silverlight and browser-plugin clients↳A web front end, or a mobile app
There is nothing to migrate to — the runtime is gone from every browser. These start as a scoping conversation about what the application actually needed to do.
2008 – 2019DataSets, EF6 and hand-rolled ADO.NET↳EF Core, or Dapper where it earns it
The data layer is where a straightforward port turns expensive. Query translation, transactions and lazy loading all behave differently, and it shows up in production rather than at compile time.
2009 – 2016ASP.NET MVC 5 and Web API 2↳ASP.NET Core MVC
The closest thing to a mechanical port on this list. The real work is hosting, configuration, dependency injection and the middleware pipeline — not your controllers.
2002 – todayWinForms and WPF↳Current .NET desktop, or MAUI if it belongs on a phone
Both still run on modern .NET, so this is rarely a rewrite. What blocks it is abandoned third-party control suites and COM interop, which is the first thing we go looking for.
Any version.NET Framework class libraries↳Current .NET, multi-targeted during the move
Shared libraries are what let the old and new systems run side by side. Getting them multi-targeting first is usually the unlock for everything else on this list.
Ongoingpackages.config, legacy csproj, IIS on Windows Server↳SDK-style projects, containers, CI that runs itself
Unglamorous, and it is what makes the rest repeatable. It also pays off long before the migration finishes, which is why it is often the right thing to do first.
No big-bang rewrites
Nothing on this list gets replaced in a single drop. The shape that works is a strangler: stand the new stack up beside the old one, move a slice at a time behind the same URLs, and keep both running until there is nothing left on the old side. It looks slower on paper, and it is the only version of this we have seen finish.