The .NET 10 Migration Playbook for Long-Lived Line-of-Business Apps

Microsoft made a quiet announcement that catches a lot of teams out: .NET 8 and .NET 9 both reach end of support on 10 November 2026. The standard support window was extended from 18 to 24 months, which has the effect of consolidating both versions onto the same end-of-life date. .NET 10, released in November 2025, is the LTS replacement, supported until November 2028.

That gives most organisations roughly six months to plan, execute and verify a migration. For a single small web app that is plenty of time. For a portfolio of long-lived line-of-business applications, with shared libraries, scheduled jobs, integrations, and the inevitable bits no-one quite remembers building, it is enough — but only if you start now.

This is the playbook we use when we are brought in to migrate a .NET estate. It is opinionated, drawn from real client projects, and written for engineering leads who need to convince a budget holder this is worth doing properly.

Why You Cannot Just Sit on .NET 8

We hear this every cycle: “the app works, we don’t need new features, why migrate?” The reasons are not glamorous, but they are firm:

No security patches. After November 2026, vulnerabilities in the framework are your problem. For internet-facing applications or anything handling regulated data, that is not a tenable position.
Cloud platforms move on. Azure App Service, Container Apps, AKS images, and most other managed runtimes deprecate unsupported framework versions within a few months of EOL. You can keep running, but you lose access to new features, and eventually you lose the ability to deploy.
Library ecosystem drift. New versions of EF Core, ASP.NET, Microsoft.Extensions.* and the wider NuGet ecosystem start dropping support for older frameworks within a release or two of EOL. You end up pinned to old versions of everything, which then constrains your other dependencies.
Hiring and morale. Engineers do not want to work on an unsupported platform. It is a recruitment liability and a retention one.

The path of least resistance is the migration.

.NET 10 Is Genuinely a Good Target

Before we get to the work, the encouraging part: .NET 10 is a strong release, not a placeholder.

C# 14 adds extension members, field-backed properties, and several quality-of-life improvements that meaningfully reduce boilerplate.
Performance continues its trajectory — Microsoft describes it as “the fastest .NET yet,” with measurable wins in JIT, GC, and minimal API throughput.
AOT compilation is more capable than in .NET 9, with broader library compatibility and smaller binaries.
Aspire 13 for distributed application orchestration is a notable step forward if you are running anything more complex than a single web app.
Tooling, including Visual Studio 2026 and an AI-assisted upgrade agent, makes the mechanics of migration noticeably less painful than in previous cycles.

The trade-off worth flagging up front: .NET 10 requires Visual Studio 2026. Visual Studio 2022 cannot target .NET 10 or use C# 14 features. If your build pipelines are pinned to specific Visual Studio versions, that is a dependency to surface early.

The Migration Playbook

Phase 1: Inventory and Triage (Week 1-2)

Before changing any code, build an inventory. For each application:

Current .NET version (8 or 9 — both are EOL on the same date)
Hosting model (Azure App Service, AKS, on-prem IIS, Windows Service, console)
Project type (web, API, worker, library, desktop)
Top 10 NuGet dependencies and their current versions
Authentication mechanism (cookie, JWT, Microsoft Identity, custom)
Whether the team that built it is still around

Sort the result into three buckets: straightforward (modern .NET 8 web API with maintained dependencies), moderate (older patterns, some legacy NuGet packages), and risky (custom hosting, deprecated APIs, no maintainer). Tackle them in that order — easy wins first build confidence and free up time for the difficult ones.

Phase 2: Address the Known Breaking Changes (Week 3-4)

Most .NET 8 → 10 migrations are smoother than the framework-to-Core jump of the late 2010s, but a handful of breaking changes catch teams out:

Legacy WebHostBuilder is deprecated, with all paths converging on WebApplicationBuilder. If you are still using the old Startup.cs pattern, that is the first thing to convert.
Identity changes. ASP.NET Identity defaults have shifted, particularly around token providers and password hashing. Test your authentication flows end-to-end.
System.Text.Json continues to tighten defaults. Some payloads that round-tripped in .NET 8 will need explicit JsonSerializerOptions in .NET 10.
HttpClient and resilience. The Polly-based resilience handlers are now the recommended pattern; older HttpClientFactory code keeps working but is the next thing to be sunset.
EF Core 10 sharpens query translation and may surface query bugs that were previously masked. Run your full integration test suite against the new EF version before assuming nothing has changed.

The migration tooling — dotnet tool install -g upgrade-assistant and the AI-assisted agent in Visual Studio 2026 — handles the mechanical changes well. Use it, but do not trust it. Review every change it proposes.

Phase 3: Pilot the Easy Application (Week 4-6)

Pick one application from the “straightforward” bucket and migrate it end-to-end. Treat this as a learning exercise: you are calibrating how long it actually takes, what your CI/CD pipeline needs, where your test coverage is weak, and how your hosting environment behaves under the new runtime.

Resist the temptation to make architectural improvements at the same time. The migration is hard enough on its own merits; turning it into a refactor doubles the risk and makes regressions harder to attribute. Lift, shift, verify. Refactor after.

Phase 4: Roll Through the Estate (Month 2-4)

With one application live on .NET 10 and the lessons captured, work through the rest of the portfolio in priority order. We typically aim for one application per fortnight for medium-complexity systems, faster for simple ones. Budget more time for the risky bucket — those are the ones where you discover a custom dependency that has not been touched in five years, or an authentication library that has been silently abandoned.

For each migration:

Update target framework and rebuild
Address compiler warnings (treat warnings as errors during migration — they reveal real issues)
Run the full automated test suite
Deploy to a staging environment and run smoke tests
Performance-compare against the previous version
Monitor closely for the first week in production

Phase 5: The Awkward Cases (Month 4-6)

Every estate has a handful of applications that resist clean migration. The most common patterns:

Custom hosting infrastructure built before WebApplicationBuilder existed. These usually need a careful rewrite of the startup pipeline.
Heavy reliance on a deprecated third-party library that has not been ported. Options: find a replacement, fork and maintain, or replace the feature.
Windows-specific code (registry access, native interop, COM) that ran fine on .NET Framework and is now harder to maintain. Often the right answer here is a tactical re-platform rather than a like-for-like port.
Internal NuGet packages with their own outdated target frameworks. Migrate these first; downstream applications cannot move until the libraries do.

These are the cases where experience matters. Budget more time, and consider whether some of them are better candidates for rewrite than migration.

Phase 6: Verify and Document (Month 6)

Before declaring the estate migrated, build a verification checklist:

All applications target net10.0
CI pipelines build, test and deploy on the new SDK
No remaining references to deprecated APIs in the codebase
Hosting environments running .NET 10 runtime
Monitoring and alerting calibrated to the new performance baseline
Updated runbooks reflecting any operational changes

Document what changed and why. The next migration cycle starts in roughly three years; future-you will be grateful.

What We Have Learned Doing This for Clients

A few patterns that keep coming up across the migration projects we have run this year:

The mechanical part is faster than expected. The upgrade tooling has matured, and most .NET 8 code lifts to .NET 10 with minimal intervention.
The non-mechanical part is slower than expected. Authentication, third-party libraries with bespoke .NET 8 builds, and infrastructure pipelines pinned to old SDK versions are where time gets eaten.
Test coverage matters more than ever. Migrations expose every assumption your test suite makes. Teams with thin coverage end up testing in production, and it shows.
Performance usually improves, sometimes meaningfully. We have seen API response times drop 15-25% on workloads that did not change.
Hosting decisions are worth revisiting. A migration is a natural moment to ask whether your current hosting model is still right. Several of our clients have moved from App Service Plans to Container Apps as part of the same exercise, with material cost savings.

A Realistic Six-Month Timeline

For a typical mid-sized .NET estate — say 15 to 30 applications — the timeline looks roughly like this:

Month	Focus
May - early June	Inventory, triage, tooling setup, pilot one easy app
June - July	Roll through the straightforward bucket (60% of estate)
August - September	Moderate-complexity applications, internal libraries
October	Risky and bespoke cases, awkward dependencies
Early November	Final verification, runbooks, decommissioning of old SDK

That sequence leaves a buffer before the 10 November deadline, which you will want. Migrations always discover something in the last fortnight.

Get Started

If you are looking at a .NET estate and weighing up whether to tackle the migration internally or with help, get in touch. We have run dozens of these migrations over the years, and the playbook above is the result. We work alongside in-house teams as well as taking the project end-to-end; either way, the goal is the same — onto LTS, before November, without drama.