Upgrading from .NET 8 to .NET 10

.NET 8 reaches end of support on November 10, 2026. After that it gets no security fixes. .NET 10, released in November 2025, is the current long-term support (LTS) release and is supported for three years.

If you skipped .NET 9, the jump to 10 is still a normal upgrade. Here's how to do it without drama.

#1. Check the platforms first

Before touching code, confirm that everything your app runs on supports .NET 10: App Service or Container Apps, Azure Functions, your container base images, your build agents, and any self-hosted infrastructure. The code change is usually the easy part.

#2. Pin the SDK

Add a global.json at the root of the repo so everyone, including CI, builds with the same SDK:

{
  "sdk": {
    "version": "10.0.100",
    "rollForward": "latestFeature"
  }
}

Update your pipeline's SDK install step to match.

#3. Change the target framework

<TargetFramework>net10.0</TargetFramework>

If you set it in many projects, consider a Directory.Build.props file so it lives in one place next time.

#4. Update packages

Bring Microsoft.* and System.* packages up to their 10.x versions, then check third-party ones:

dotnet list package --outdated

Upgrade packages in their own commit, separate from code fixes, so it's easy to see what changed if something breaks.

#5. Read the breaking changes

Microsoft publishes a list of breaking changes for each release, grouped by area such as ASP.NET Core, EF Core and SDK. Skim the areas you use. Most entries won't apply to you, and the ones that do are much easier to deal with up front than to discover in production.

#6. Build with warnings on

New analyzers and nullable annotations in the framework often surface new warnings. Read them rather than suppressing them: some point at real bugs.

#7. Test, then deploy gradually

• Run the full test suite, including integration tests against real dependencies.
• Deploy to a staging environment or slot first and watch error rates, memory and response times.
• For services with several instances, roll out gradually where your platform allows it.

#8. Update the container images

If you build containers, switch the base images to the 10.0 tags, for example mcr.microsoft.com/dotnet/aspnet:10.0, and rebuild. Forgetting this is a common way to end up running the old runtime after "upgrading".

#Takeaway

Start with the platforms, pin the SDK, upgrade the target framework and packages in separate steps, read the breaking changes for the areas you use, and roll out through staging. Doing it well before November 2026 means you won't be upgrading under deadline pressure.