Engineering Practitioner Brief / 18 May 2026

.NET Framework Legacy Cost

Microsoft ended new-feature development for .NET Framework at version 4.8 in 2019. Security patches continue as part of Windows, but the .NET cross-platform line (currently .NET 9, with .NET 10 LTS landing November 2025) is the supported destination. The migration is structurally a port to a different runtime, not a version upgrade, which is why it costs more than the equivalent Spring or Django ladder. This page breaks down the per-component cost.

The Three Cost Tiers by Application Shape

The .NET Upgrade Assistant

Microsoft's .NET Upgrade Assistant handles the mechanical part of the migration well: project file conversion (from packages.config or PackageReference to SDK-style), target framework moniker updates, NuGet package upgrades for known-compatible alternatives, and namespace adjustments. The tool also flags APIs that have no direct .NET equivalent and need substitution.

For a 100K-line ASP.NET MVC application without WebForms or WCF server components, the Upgrade Assistant typically completes its mechanical pass in 4 to 12 engineer-hours. The output is a compiling project on .NET that may or may not run correctly; the runtime verification and behavioural test work is the bulk of the remaining migration effort.

ASP.NET MVC to ASP.NET Core MVC

The cleanest migration in the .NET Framework world. ASP.NET MVC and ASP.NET Core MVC share most of the API surface (controllers, model binding, routing). The differences that matter:

• Startup configuration: Global.asax replaced by Program.cs and Startup.cs (Program.cs only in newer templates).
• Dependency injection: built-in DI container in ASP.NET Core, replacing third-party DI containers like Autofac or Unity (or keeping them with the Microsoft.Extensions.DependencyInjection bridge).
• System.Web removed: HttpContext is now Microsoft.AspNetCore.Http.HttpContext, with a different API. Anything that touched System.Web.HttpContext.Current needs a rewrite to access HttpContext via IHttpContextAccessor.
• Web.config replaced by appsettings.json and IConfiguration. Most settings transfer with limited change.

Typical effort for a 100K-line MVC application: 200 to 500 engineer-hours including the dependency-injection refactor and the System.Web removal.

WebForms Exit

The most expensive single component of .NET Framework legacy work. WebForms (server-side controls, ViewState, the page lifecycle, code-behind files) is fundamentally incompatible with .NET's stateless request model. There is no automated migration path. Every WebForms page is a manual rewrite to one of the alternatives.

• Blazor Server. Closest to WebForms' event-driven model. The migration is still a rewrite but the developer mental model transfers reasonably. Best for internal LOB applications where the SignalR persistent connection is acceptable.
• Blazor WebAssembly. Client-side execution model, no SignalR dependency, but larger initial download and harder SEO. Best for SaaS apps where the user is already authenticated and offline support has value.
• Razor Pages. Page-oriented model, simpler than full MVC, suitable for primarily server-rendered applications. Lowest migration cost when WebForms pages mapped cleanly to URL paths.
• ASP.NET Core MVC. Best for applications that already think in controller-action terms and only used WebForms because it was the default at the time.

Effort sizing for a 100-page WebForms application: 1,200 to 3,000 engineer-hours depending on the chosen target. The high end applies to applications with heavy use of server controls and ViewState, which need explicit state-management refactoring.

WCF Service Replacement

.NET does not include WCF server-side support. Three replacement options have emerged:

CoreWCF is a community-maintained .NET-compatible WCF implementation. It supports a meaningful subset of the original WCF surface area, primarily SOAP over HTTP and TCP bindings. For applications that need to maintain existing WCF clients, CoreWCF is the lowest-friction path. Migration effort: 30 to 100 engineer-hours per service for the typical case.

gRPC is the modern equivalent for high-performance internal service-to-service communication. The proto-first contract is a different mental model from WCF's attribute-based contract definition. Migration effort: 80 to 200 engineer-hours per service plus client rewrites.

REST plus OpenAPI is the most common choice for external-facing services. The contract translation is straightforward (WCF DataContracts to JSON DTOs) but client SDKs need to be regenerated. Migration effort: 60 to 150 engineer-hours per service.

IIS to Kestrel and Linux Containers

.NET runs cross-platform, most often on Linux in containers in production. The migration off IIS to Kestrel (the cross-platform Microsoft web server) and Linux containers is the operational half of the .NET Framework to .NET migration. The compute-cost story is favourable: a typical web workload runs at 50 to 70 percent of the equivalent IIS-on-Windows cost when moved to Kestrel on Linux, primarily because of OS license cost differences and better container density.

The engineering cost is in operational rebuild: deployment pipelines, monitoring agents, log shipping, and the runbooks that describe how the application is operated. A team moving from an IIS-managed-by-ops deployment to a Kubernetes-on-Linux deployment is doing two migrations in one. Plan an additional 200 to 500 engineer-hours per application for the operational rebuild, depending on how much of the operational tooling is shared across applications.

AppDomain Removal

.NET Framework supported AppDomain isolation, which allowed loading and unloading plugin assemblies in the same process with isolated memory. .NET removed full AppDomain support. The partial replacement is AssemblyLoadContext, which allows loading and unloading assemblies but does not provide the security isolation that AppDomains did.

Applications that relied on AppDomain isolation for security (sandboxing third-party plugins) need to redesign. The modern equivalent is process-level isolation: each plugin runs in a separate process, communicating via IPC or HTTP. This is more expensive operationally but provides stronger isolation. Migration effort for an AppDomain-heavy application is 400 to 1,500 engineer-hours; this is one of the components that pushes large .NET Framework migrations above the $1M mark.

Related Reading

• Framework migration cost
• Java and Spring legacy cost
• COBOL mainframe debt cost
• Monolith decomposition cost
• Dependency debt cost

Frequently Asked Questions