Microsoft’s current .NET support policy lists the same end-of-support date for .NET 8 LTS and .NET 9 STS: 10 November 2026. .NET 10 LTS remains supported until 14 November 2028. .NET 8 and 9 are already in maintenance support, which means Microsoft is providing security updates only. Customers must also remain current on released patches to qualify for support.

For production teams already migrating, the immediate risk is a definition of completion that covers the application code while missing the runtime, dependencies, containers, build environment or self-contained releases.

Changing TargetFramework to net10.0 and producing a successful build does not prove that a production system has been upgraded. The work is complete when the supported version can be built, deployed, operated and recovered across every in-scope deployment route.

Treat the migration as a production release

Applications running on .NET 8 or 9 will not stop on 11 November. Microsoft will, however, stop providing fixes, updates and online technical assistance for those releases. Any vulnerability discovered after that point will not receive a .NET 8 or 9 fix through normal Microsoft servicing, although teams may sometimes be able to apply a compensating mitigation while completing the upgrade.

Running an unsupported release may also create an exception under a company’s security policy, customer commitments or software-support requirements. Until the migration is released, teams should keep their .NET 8 and 9 installations on the latest available patches.

Management should define the scope by deployed workloads rather than repositories or completed development tickets. Before the migration is signed off, each team should be able to confirm that:

• every in-scope .NET 8 or 9 application has moved to a supported version;
• every environment that runs it uses an operating system and architecture supported by .NET 10 and provides the required runtime;
• direct, transitive and internal dependencies remain compatible and adequately maintained;
• container and self-contained artifacts have been rebuilt;
• CI/CD produces the intended .NET 10 artifact from a clean environment;
• that artifact has passed production-relevant tests and has a workable rollback or roll-forward recovery route.

This prevents a migration from appearing complete while an overlooked background service, installer, disaster-recovery host or customer-specific deployment still contains .NET 8 or 9.

Can applications move directly to .NET 10?

In most cases, yes. A .NET 8 application does not need to be released on .NET 9 before it moves to .NET 10. Since .NET 9 reaches end of support on the same day, treating it as the final destination would not extend the support window.

A team moving from .NET 8 should review the changes introduced in both .NET 9 and .NET 10. A team already running .NET 9 needs to review the .NET 10 changes.

Microsoft classifies breaking changes as source incompatibilities, binary incompatibilities and behavioural changes. Compilation will expose many source problems, but it will not reliably reveal binary or behavioural problems. Authentication, serialization, database access, configuration, background processing and external integrations therefore require functional testing.

Microsoft also describes the .NET 10 compatibility list as incomplete, so it should be treated as a starting point rather than a replacement for application-specific tests.

Large systems may still require a staged release. Shared libraries should be reviewed in dependency order, but because .NET 10 continues to support .NET Standard 2.0 and 2.1, a compatible library does not need to be retargeted solely because a consuming application moves to .NET 10. Libraries that do require changes can move before applications, and independently deployed services can be released separately. This is a sequencing decision rather than a requirement to operate temporarily on .NET 9.

What must production teams upgrade?

Retargeting the application is only the first step. Production readiness depends on five connected areas:

• Runtime and hosting. Framework-dependent applications need .NET 10 in every environment that runs them, including relevant IIS hosting bundles and managed cloud settings. The operating system version and architecture must also appear in Microsoft’s .NET 10 support matrix; the ability to install the runtime does not by itself establish a supported production configuration. Teams should verify which runtime the deployed process actually resolves.
  
• Dependencies. Managed packages and internal libraries must support the new target. Database providers, authentication components and other independently versioned packages also need to remain within any support policy required by the organisation. Native dependencies must be compatible with the target operating system, architecture and container base. Any blocker affecting several applications needs a named owner and a decision on whether to upgrade, replace or isolate it. Using Microsoft’s package-list command, teams with the .NET 10 SDK can run dotnet package list --outdated, dotnet package list --deprecated and dotnet package list --vulnerable --include-transitive as separate checks. The equivalent command on .NET 9 and earlier SDKs begins dotnet list package.
  
• Containers. Build and runtime images must be updated, rebuilt and tested. As Microsoft’s .NET 10 container guidance explains, default Linux tags that do not specify an operating system now use Ubuntu 24.04 instead of Debian, which may affect operating-system packages and native dependencies. Kubernetes manifests, Helm charts and recovery configurations must also reference the new images.
  
• Self-contained deployments. Under Microsoft’s self-contained deployment model, the application bundles its own runtime, so installing .NET 10 on the host has no effect. Every supported operating system, architecture and distribution channel used by the application requires a new artifact. Future runtime security patches will also require rebuilding and republishing.
  
• CI/CD. The pipeline must have access to an appropriate .NET 10 SDK. Version selection may be controlled through global.json, pipeline tasks, build-agent images or Docker build stages. Publish profiles, infrastructure code and deployment definitions must produce and reference the intended artifact. Completion should be proven by a clean pipeline build and tests against the exact package or image that will reach production.

From a management perspective, the migration is complete only when every supported deployment route produces an artifact that can be deployed, operated and recovered on .NET 10.

Measure production readiness, not migration activity

The final part of a migration often contains more uncertainty than the initial retargeting. The remaining work may sit in one unsupported package, a brittle integration, missing regression tests or a deployment path owned by another team.

A useful management view should report:

• which production workloads have been released on .NET 10;
• the business criticality of the workloads that remain;
• what blocks each remaining workload;
• who owns every blocker and when a decision is required;
• what test evidence supports release approval;
• which deployment window and recovery route have been agreed;
• which workloads are expected to remain on .NET 8 or 9 after 10 November.

Raw workload counts can be misleading. Migrating ten minor jobs does not compensate for leaving the main transactional platform unsupported. Progress should therefore be assessed against business criticality and residual production risk, not only the number of completed projects or pull requests.

Database schema changes, message contracts or independently deployed services may make rollback unsafe even when the previous application artifact remains available. Those releases need backward-compatible changes that preserve rollback or a tested roll-forward recovery route. Where a rollback to .NET 8 or 9 remains technically possible after the deadline, it would restore an unsupported production state and should be treated as a time-limited exception with a defined route back to .NET 10.

When a custom AI migration harness is justified

Microsoft now provides a GitHub Copilot upgrade agent that can assess .NET projects, prepare an upgrade plan, apply code fixes and validate builds and tests. For one or a few applications, this agent and the normal engineering toolchain may be sufficient.

A custom AI migration harness is justified when the same controlled process must be applied across many repositories, internal packages and company-specific delivery rules, and the repeated work clearly outweighs the setup and review cost.

It should operate as a bounded engineering loop:

1. Create a structured inventory. Scripts collect target frameworks, dependency graphs, package risks, Dockerfiles, pipeline definitions and test commands.
   
2. Divide the work into reviewable changes. AI proposes a sequence based on dependency order, official compatibility guidance and the company’s approved package and architecture rules.
   
3. Apply one defined change. The model may update project files, package references, obsolete APIs, container tags or pipeline configuration within an agreed scope.
   
4. Run deterministic checks. The process runs the builds, analyzers, tests, package audits and container checks defined for that workstream. The result is evaluated according to the project’s existing quality and security policy.
   
5. Require senior review. A developer reviews behaviour, architecture, permissions, data access and production assumptions before the change can proceed.

This can reduce the manual effort spent locating and repeating predictable changes across many services. It does not remove the need for senior judgement where behaviour depends on undocumented business rules, external systems or weak test coverage.

Management should judge the process by accepted production migrations rather than generated changes. If AI produces patches faster but creates more review and correction work, it has moved the bottleneck rather than added delivery capacity.

When the migration needs additional senior capacity

For teams that are falling behind, the problem usually isn't a lack of general .NET knowledge. The remaining tasks require the same senior developers who are also responsible for architecture, reviews, incidents and committed product releases.

The application may compile on .NET 10 but still be unreleasable. One dependency may block several services, container and pipeline work may remain unfinished, or existing tests may not provide enough confidence.

At that point, assigning more migration work to the internal technical leads can protect the deadline only by delaying other critical delivery.

Blocshop can add one to three senior .NET developers directly to the existing team and backlog for the period in which that additional ownership is needed. They can take responsibility for a bounded workstream such as a blocked dependency path, a defined group of services, container and CI/CD changes, missing regression coverage or release preparation.

Work begins by isolating a workstream that can progress with limited domain onboarding and agreeing its repositories, acceptance criteria, first production-relevant deliverable and handover point. The client’s technical leads retain architectural control, while Blocshop carries the agreed work through implementation, testing and production release.

Blocshop’s .NET and Azure work for BCC, for example, began with a defined checkout project and developed into a long-term engagement that included migrating legacy e-commerce systems to a microservices architecture. Where repeated changes across many repositories justify it, the same team can add a controlled AI migration process while senior developers remain responsible for the accepted result.

Is one unresolved workstream now threatening the 10 November deadline or displacing your product delivery? Book a consultation with Blocshop and bring the blocker consuming the most senior engineering time.

Together, we will determine whether Blocshop can take responsibility for it with limited domain onboarding, what the first production deliverable should be and what evidence would mark it complete, giving you a concrete scope before you decide whether to proceed.