Migrating from .NET 8 to .NET 10: the practical freelance guide

.NET 8 and .NET 9 remain supported until 10 November 2026. Microsoft servicing and security updates end then; applications will continue to run. For a .NET 8 application, preparing a move to .NET 10 LTS means reviewing code, dependencies, hosting and business workflows. This guide sets out the steps and the evidence needed before deployment.

Verified support dates for .NET 8, 9 and 10

• .NET 8 LTS, released on 14 November 2023: support ends on 10 November 2026.
• .NET 9 STS, released on 12 November 2024: support ends on 10 November 2026. STS releases now receive 24 months of support.
• .NET 10 LTS, released on 11 November 2025: supported through November 2028.

These dates were checked on 23 October 2026 against Microsoft’s .NET 8 and 9 end-of-support announcement. This guide corrects its earlier statement that .NET 9 support ended in May. With 10 November approaching, first identify exposed applications, blocking dependencies and available testing windows. A realistic schedule depends on that inventory rather than a standard duration.

To establish that inventory, request a .NET migration assessment: describe the applications, hosting, sensitive dependencies and deadline.

Can you upgrade directly from .NET 8 to .NET 10?

Yes, an application can target net10.0 directly. Deploying .NET 9 to production is not a prerequisite, but changes introduced in both versions need review. .NET 9 provides no additional support runway compared with .NET 8. Temporary multi-targeting for a shared library can allow consuming applications to migrate separately.

A .NET Framework 4.x application requires a separate porting assessment: review its libraries, Windows APIs and web components before applying this sequence. The .NET application takeover and migration service starts by making that distinction.

Step 1: establish a baseline before changing code

Inventory solutions, projects, external services, databases, scheduled jobs and deployment platforms. Record the SDK with dotnet --info and direct and transitive packages with dotnet list package --include-transitive. Check maintenance and compatibility; a compatible library does not necessarily need a major upgrade solely because the runtime changes.

Run critical workflows on the current version and retain expected results: API responses, authorisation rules, exports and database writes. Measure response times and resource use with representative data. Where tests are missing, first protect those workflows with reproducible integration tests.

Step 2: align the SDK, projects, packages and hosting

• Install a maintained .NET 10 SDK on development machines and CI agents; align global.json with the installed version.
• Change TargetFramework to net10.0, or the relevant platform-specific target. Update affected Microsoft package references and EF Core providers to mutually compatible versions.
• Run dotnet restore, dotnet build and dotnet test. Review warnings, transitive dependencies and behaviour after compilation.
• Align hosting: runtime or Hosting Bundle, Docker build and runtime images, operating system, processor architecture and self-contained publishing where applicable.

Microsoft documents upgrading .NET and migrating ASP.NET Core to .NET 10. Adapt the steps to your workloads; editing the project file does not validate business exchanges.

Step 3: address .NET 9 and 10 breaking changes

Review the .NET 9 and .NET 10 inventories by technology. For each applicable change, record the affected component, the decision and the test proving the outcome. Breaking changes can affect source code, binary loading or runtime behaviour; a successful build does not rule out behavioural changes.

• EF Core 9: applying migrations throws when the model contains pending changes not included in a migration. Check the model and scripts against a representative database copy. EF Core 9 breaking changes.
• EF Core 10: tooling requires --framework for multi-targeted projects. Check migration generation and application commands in CI. Also review generated SQL changes with your provider. EF Core 10 breaking changes.
• APIs, authentication and serialisation: compare applicable changes with actual contracts. Test existing clients, access denials, null values and date formats, alongside successful responses.

Step 4: prepare acceptance evidence and rollback

The record should associate each scenario with a release version, input data, expected business result and evidence. Agree performance thresholds before comparing results under similar conditions. A runtime upgrade alone does not guarantee a speed improvement.

• Business workflows: reading, creation, amendment and cancellation, permissions and denials, exports and scheduled jobs.
• Data and interfaces: schema migrations, concurrency, transactions, JSON contracts and external service errors.
• Operations: staging deployment, restart, logs, alerts, representative load and observation.
• Rollback: previous artifact available, recoverable configuration, schema compatibility and treatment of data already written. Test the procedure; restoring the previous binary does not restore the database.

What a migration assessment delivers

An initial scope can cover one solution and its delivery path. Deliverables comprise a dependency and blocker inventory, applicable breaking changes, migration batches, acceptance criteria and an estimate conditional on identified risks. Fixes and production deployment are then scoped from that evidence. See the .NET service for the engagement process.