What It Takes to Upgrade to .NET 10

Breaking changes, dependency debt, and where the hours go. Here's a preview for teams planning ahead.

With .NET 11 shipping in November 2026 and .NET 8 hitting end-of-life the same month, teams are doing the math. The question that keeps surfacing in sprint planning and architecture reviews is some version of: what's it going to take to upgrade to .NET 10. 

This post answers that in terms of effort, not budget. Breaking changes, dependency risk, validation overhead, and where projects slow down. 

First: Know Which Upgrade You're Doing

This matters more than most teams realize.

If you're on .NET 8 or, and if this is you, act now, .NET 9 (which went EOL in May 2026), you're moving within the modern .NET runtime. Same architecture, same SDK toolchain, same compilation model. Microsoft designed this versioning cadence for incremental, low-disruption upgrades, and the 8→10 LTS hop is a good example of that working as intended.

If you're on .NET Framework, any version, you're doing a platform migration. That's a different project with a different risk profile and a different conversation. We'll address that separately; it deserves its own post.

Everything below assumes you're on .NET 8 or 9.

The Answer

For most applications on modern .NET, upgrading to .NET 10 will take less than you're probably budgeting for. Microsoft publishes a complete breaking changes list for every release. For the 8→10 window, it's dozens of entries, targeted, documented, and largely caught by build-time analyzers. There's no architectural rework. There's no API surface cliff. The effort is mostly mechanical.

The uncertainty in your estimate is around your test coverage and your dependency graph. Both of those are solvable but they're where surprises live.

Where the Work Goes

1. Breaking Changes Audit (2–8 hours)

Start with Microsoft's published breaking changes list for .NET 10. For a typical LTS-to-LTS jump, the list is manageable and scoped; behavior changes in specific APIs, not platform-wide rewrites.

The areas worth close attention in the 8→10 window:

• System.Text.Json — if you're using custom converters or non-default serialization behavior, check this section first. Serialization semantics have had targeted adjustments across recent releases.
• ASP.NET Core middleware — minimal API binding and routing edge cases. Most apps won't hit these, but review if you've customized the pipeline.
• LINQ behavioral edge cases — a handful of operators with changed null-handling or ordering semantics. Run your tests.
• P/Invoke and interop — if you're calling native code, check the interop section. Usually not relevant for line-of-business applications.

The Microsoft.DotNet.Compatibility analyzer flags affected call sites at build time. Run it before you start manually reviewing anything — it narrows the list quickly.

For the average application, the real breaking changes audit takes an afternoon. If your codebase is large but well-structured, a day.

2. NuGet Dependency Compatibility Sweep (4-16 hours)

This is where teams consistently underestimate effort, and it's worth spending time here before you start the upgrade.

Your application code may compile cleanly against .NET 10. Your packages need to as well. Most major ecosystem packages (Entity Framework Core, Serilog, MediatR, Polly, Dapper, AutoMapper) ship updates synchronized with or shortly before major .NET releases. These aren't usually a problem.

What slows you down:

• Unmaintained packages — anything that hasn't shipped an update in 12-18 months is a flag. Check whether the maintainer is still active and whether a .NET 10 target framework moniker (TFM) appears in the release notes.
• Version pins in your lockfile — if you've hard-pinned packages for stability, you may be pulling in older versions that predate .NET 10 compatibility declarations.
• Internal packages — NuGet packages your team owns also need their own TFM updates. If you have shared libraries published internally, those upgrades need to happen before, or in parallel with, the consuming application.
• Transitive dependencies — a package you depend on may itself depend on something incompatible. dotnet-outdated helps surface these; so does a build with detailed restore logging.

A clean dependency graph with well-maintained packages: half a day. Significant dependency debt with some abandoned packages: potentially a week, because some of those packages need to be forked, replaced, or wrapped.

Do the dependency audit before you commit to a timeline. It's the most variable input.

3. SDK and Build Pipeline Updates (2-4 hours)

Mechanical, but don't skip it.

• Update global.json to pin the .NET 10 SDK version
• Update <TargetFramework> (or <TargetFrameworks>) in each .csproj
• Update Docker base images (mcr.microsoft.com/dotnet/aspnet:10.0, etc.)
• Update CI/CD pipeline definitions to use .NET 10 runner images (GitHub Actions, Azure DevOps, and others will have these at GA)
• Update any build scripts that reference SDK paths or version-specific binaries

None of this is where projects stall. It's just time that needs to be accounted for.

4. Test Suite Validation (the variable that drives your estimate)

This part of the estimate is easy to underestimate: the work isn't usually in making code changes; it's in having enough confidence to ship after you do.

If your test coverage is strong and your suite is well-maintained, the flow is clean: bump the TFM, run the suite, fix the handful of failures (usually a few breaking change hits or package behavior changes), ship. Teams with solid coverage have done this in a day.

If your coverage is thin, you're validating manually. That means QA cycles, regression testing against production data patterns, and often discovering issues you'd normally catch automatically. The .NET 10 upgrade didn't create these risks. They existed before. But the version change surfaces them.

Practical guidance: before you schedule the upgrade, run your test suite as-is and check coverage on your critical paths. If you're below 60-70% on business logic, you'll spend more time on validation than on the upgrade itself. That's a signal to address coverage first, or to budget more time for manual QA.

5. Optional: New Feature Adoption

.NET 10 ships legit improvements: runtime performance gains across the board, new C# language features, Blazor rendering and interop enhancements, expanded HTTP/3 support, expanded AOT compilation targets, and lots more.

Adopting these is decoupled from the version upgrade. You can update your TFM, ship to .NET 10, and not change a line of application logic. New language features, new APIs, and performance-sensitive refactors are a second wave. Plan them separately.

Don't let new feature interest inflate your upgrade estimate, and don't let upgrade pressure foreclose thoughtful feature adoption planning.

Effort Ranges

For a moderately complex application with clean architecture and reasonable coverage:

The wide range isn't .NET 10's fault. It's a function of prior investment decisions in dependency hygiene and test infrastructure.

What This Post Doesn't Cover

If you read this and felt relief. Good. The modern .NET versioning model is designed to make this tractable, and it mostly succeeds.

But a meaningful percentage of the teams asking "what does it cost to upgrade to .NET 10?" are usually on .NET Framework and hoping the answer is similar. It isn't.

Framework → .NET is a platform migration: a different runtime, a different hosting model, a different deployment story, and in most cases a different API surface requiring application-level changes. For applications built on VB6, WebForms, WCF, or PowerBuilder, there's often no supported migration toolchain without specialized help and the effort starts at weeks and scales from there based on application complexity and language.

If that's your situation, the .NET 10 upgrade timeline isn't your constraint. The Framework → .NET migration roadmap is. That's a different conversation, and one worth having before November.

GAPVelocity AI builds VELO, an agentic modernization platform for legacy codebases including VB6, PowerBuilder, WebForms, and Access targeting .NET and Blazor on Azure. If your modernization question goes beyond a TFM bump, we can help.