Migrating from .NET Framework to .NET 8 — What Actually Happens

The .NET Framework is not dead. Microsoft will continue to support .NET Framework 4.8 indefinitely on Windows. But it is end of innovation — no new features, no cross-platform capability, no modern performance improvements, and an increasingly difficult developer hiring story as the ecosystem moves on.

.NET 8 is the current long-term support version. It is faster, cross-platform, supports modern deployment patterns, and is where all Microsoft investment is going. The migration is real work — but it is entirely achievable on production codebases, and we've done it enough times to know what actually causes problems.

Businesses choose .NET 8 migration to improve performance, enable cloud deployment, reduce infrastructure costs, and support modern integrations like APIs and AI systems.

What actually breaks

One of the most common questions is: what breaks when migrating from .NET Framework to .NET 8?

The honest answer is: less than your team fears, more than Microsoft's blog posts suggest. Here's the real catalogue of what causes migration work:

The migration approach that works

This section explains how to migrate from .NET Framework to .NET 8 step by step using a production-safe approach.

There are two broad approaches: big-bang (migrate everything at once) and incremental (migrate one project at a time, keeping the old and new running simultaneously). Big-bang fails more often than it succeeds on production codebases above about 50,000 lines. Incremental is slower but dramatically lower risk.

The strangler-fig pattern for .NET

The strangler-fig pattern means introducing .NET Core components alongside the existing .NET Framework application and routing traffic to the new components progressively. For web applications, this works at the reverse-proxy level: the same domain, different components behind the proxy routing to either the old or new application.

# New .NET 8 application handles /api/* first
location /api/v2/ {
    proxy_pass http://dotnet8-app:5000;
}

# Legacy .NET Framework still handles everything else
location / {
    proxy_pass http://dotnet-framework-app:8080;
}

# As modules migrate, add routes to .NET 8 progressively
# /orders → dotnet8, /users → dotnet8, etc.
# Legacy app shrinks, new app grows

The key principle: the legacy application continues to handle every route you haven't migrated yet. You never have a moment where "everything is migrated but nothing works." The migration happens page by page, endpoint by endpoint.

Handling Web Forms — the uncomfortable truth

A common search query is how to migrate ASP.NET Web Forms to .NET 8, and the answer is that it requires a UI rewrite.

Web Forms don't migrate. This isn't a nuance or a "with effort" situation — ASP.NET Web Forms was a Windows-only, System.Web-dependent technology that Microsoft explicitly chose not to port to .NET Core. If your application uses Web Forms, you have three options:

Option 1: Razor Pages (recommended for form-heavy applications)

Razor Pages is the closest spiritual successor to Web Forms — page-based, event model, server-side rendering. The migration effort is significant but the mental model transfer is easier than moving to a SPA framework.

Option 2: Blazor Server (for teams with existing C# expertise)

Blazor Server provides a component model with server-side C# execution. For teams who want to stay in C# and avoid JavaScript, this is viable. The performance model is different (SignalR websocket for every interaction) and needs to be appropriate for your user base.

Option 3: React/Vue front-end + .NET Core API (for modern architecture)

Decouple the front-end entirely. The .NET Core application becomes a pure API. The UI is rebuilt in React or Vue. More work upfront, but the architectural outcome is a properly separated front-end and back-end with independent deployment capability.

WCF services — the other hard one

Many teams specifically look for WCF to .NET 8 migration strategies, as WCF is not supported in modern .NET.

WCF server is not available in .NET Core. CoreWCF exists as a partial implementation for WCF clients, but if you're hosting WCF services, they need to move. The options:

gRPC is the modern replacement for WCF binary communication — better performance, contract-first, strong typing, bidirectional streaming. If your WCF services communicate with internal .NET clients, gRPC is the right target.

REST / HTTP APIs are the right choice if the services are consumed by anything external or if you want maximum interoperability. The migration from WCF to ASP.NET Core controllers is straightforward in terms of business logic transfer — the interface contract changes.

Entity Framework 6 → EF Core

EF Core is not a drop-in replacement for EF6. The mapping concepts are the same but there are genuine breaking changes:

// EF6 — lazy loading on by default
// Navigation properties loaded automatically on access

// EF Core — explicit opt-in required
services.AddDbContext<AppDbContext>(options =>
    options.UseSqlServer(connectionString)
           .UseLazyLoadingProxies()); // Not default — must opt in

// Or use explicit Include() — better for performance
var orders = context.Orders
    .Include(o => o.Customer)
    .Include(o => o.OrderLines)
    .ToList();

The most common EF6 → EF Core issues in production codebases: lazy loading assumptions throughout the codebase, raw SQL that used EF6-specific syntax, and complex many-to-many relationships that EF Core handles differently (better, but differently).

Realistic timeline by codebase type

The .NET migration cost and timeline depend heavily on architecture, dependencies, and legacy components like Web Forms or WCF.

The migration process we follow

Our team provides .NET migration services for enterprise applications, including assessment, planning, and full execution.

The question we get asked most: can we stay on Windows?

Yes. .NET 8 runs on Windows. You don't have to migrate to Linux or containers — although if you're doing the migration anyway, it's often the right moment to move to a containerised deployment on Linux hosting, which is significantly cheaper on Azure and AWS.

If you want to stay on IIS on Windows Server, .NET 8 supports that via the ASP.NET Core Module v2. The application runs in-process in IIS, similar to how .NET Framework applications run today. The hosting model is compatible; what changes is the runtime and application code.

Is it worth it?

For most .NET Framework applications, yes — but the "worth it" calculation depends heavily on what you're trying to unlock. If the primary motivation is performance, .NET 8 is genuinely faster — benchmark improvements of 2–5x on typical web API workloads versus .NET Framework 4.8 are realistic, not marketing. If the motivation is Linux/container deployment to reduce infrastructure cost, the saving is real and ongoing. If the motivation is security — end-of-life framework risk — that's a compliance and risk question, not a performance question.

If the honest answer is "we just feel like we should," that's not sufficient justification for a 12-week engineering investment. Be clear about what outcome you're buying.