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

The countdown has started: .NET 8 support ends on 10 November 2026. After that date, no more security fixes, no more patches. For applications running in production - APIs, ASP.NET Core websites, Windows services, batch processing - staying on .NET 8 beyond autumn 2026 means accepting a known, dated risk. The good news: migrating from .NET 8 to .NET 10 is one of the most reasonable version upgrades in the platform's history, provided it is carried out methodically. Here is what it really involves, the classic pitfalls, and how a senior freelance .NET developer runs this project without interrupting your business.

Why migrate now (and not in October 2026)

The .NET calendar is predictable: one major version every November, alternating LTS (3 years of support) and STS (18 months). .NET 8 is an LTS released in November 2023 and supported until 10 November 2026. .NET 9, an STS release, already fell out of support in May 2026. .NET 10, the LTS released in November 2025, is supported until November 2028: it is the natural target for every application currently on .NET 8.

Waiting until the last minute is the worst-case scenario: teams migrating in October 2026 will do it in a rush, at the same time as everyone else, with shortened testing windows. Migrating during a quiet period - typically the summer - lets you run the project calmly, keep the new version in pre-production for several weeks, and absorb surprises without calendar pressure.

Beyond security, .NET 10 brings immediate gains: runtime performance improvements with every release (JIT, garbage collector, fewer allocations) - often measurable without changing a single line of code -, the C# 14 language and its simplifications, and two years of peace of mind before the next LTS deadline.

Should you go through .NET 9? No.

A recurring question at the start of an engagement: "should we migrate one version at a time?" For a .NET 8 application the answer is no: you target .NET 10 directly. Intermediate versions are not mandatory steps - .NET 9 is in fact already out of support. An LTS-to-LTS strategy is the standard for business applications: fewer migrations, fewer test campaigns, less cumulative risk. The breaking changes of .NET 9 and .NET 10 are handled in a single pass, and Microsoft documents both lists.

What the migration really involves

On paper, migrating boils down to changing the TargetFramework from net8.0 to net10.0 and recompiling. In practice, the retarget is the visible part of a project that touches the whole delivery chain:

• The NuGet graph: every package must be raised to a .NET 10-compatible version. That is where the real difficulties hide - abandoned packages, major upgrades with their own breaking changes (EF Core 10, serialisation libraries, API clients), transitive version conflicts.
• Obsolete APIs: obsolescence warnings accumulated since .NET 8 sometimes become errors. A clean-up pass is needed, guided by the analyzers and the official breaking-changes list.
• The CI/CD chain: the SDK pinned in global.json, base Docker images (mcr.microsoft.com/dotnet/aspnet:10.0), Azure DevOps or GitHub Actions build agents, deployment scripts. A migration that forgets the pipeline breaks at the first build.
• Validation: functional testing focused on the risk areas (data access, JSON serialisation, authentication, scheduled jobs), before/after performance comparison, and an observation period in pre-production.

The classic pitfalls I meet on assignments

The first pitfall is the orphaned NuGet package: a critical dependency whose maintainer has disappeared and which will never target .NET 10. It must be detected at the start of the project - not in week 6 - and a decision made: replacement, fork, or rewriting the affected scope. The second is the internal library shared across several applications: multi-targeting it (net8.0;net10.0) during the transition avoids forcing the whole estate to migrate at once. The third is the absence of automated tests: in that case, the critical paths are first secured with integration tests before touching the framework - that is the difference between a measured migration and a leap into the void.

A special mention for applications still on .NET Framework 4.x: there, it is no longer a version upgrade but a genuine port, with a different scope and method - a subject I cover as part of my .NET development services. If your estate mixes both generations, the initial audit is precisely what lets you sequence the projects.

The method: audit, plan, migrate in batches, observe

A successful migration starts with a one-to-three-day audit: an inventory of solutions and projects, a map of the NuGet graph, detection of at-risk dependencies, the state of test coverage, a review of the delivery pipeline. The audit produces a costed, batched plan: shared libraries first (multi-targeted), then the least exposed applications, finally the critical ones - each with its own test campaign and deployment window. On most well-maintained .NET 8 estates, migrating one application takes days, not weeks; it is the state of the dependency graph that moves the bill, and that is exactly what the audit reveals before anything is committed.

Freelancer or consultancy for this project?

A .NET 8 to .NET 10 migration is a bounded, technical, tooling-heavy project: the ideal profile is a senior developer who has already done it, not a full project team. Going through a freelancer avoids the tunnel effect and the layers of intermediaries: you talk directly to the person doing the work, the start-up takes days, and the budget corresponds to real production time. With more than fifteen years of .NET - from the Framework to the current versions, with the migrations that go with them - and daily practice of Azure DevOps pipelines, I work on precisely this type of project: you will find the details of my background on my expertise page.

Remote work and availability

This type of assignment works very well remotely: the audit over video, development on your environments, continuous code reviews and demos. I work remotely for companies all across France, and I can be on site in the Hauts-de-France region (Valenciennes, Lille, Douai, Cambrai, Maubeuge) when the context requires it - scoping workshops, production cut-overs.

In summary

The end of .NET 8 support in November 2026 is neither a surprise nor a fate: it is a known deadline that can be prepared for. Target .NET 10 LTS directly, audit the dependency graph before committing to the project, migrate in batches with genuine testing, and allow an observation period: that is the method that turns a calendar constraint into a net gain - security, performance, and two years of peace of mind. If your applications are still running on .NET 8, now is the right time to talk about it - before the deadline picks the date for you.