Your .NET Upgrade Can Pass CI and Still Miss November’s Support Deadline

Microsoft’s current support policy puts .NET 8 LTS and .NET 9 STS at the same end-of-support date: 10 November 2026. Both are in maintenance support now, when updates address security vulnerabilities only. After the date, Microsoft says it will no longer provide fixes, updates or online technical assistance for those releases. The policy covers the runtime, SDK, ASP.NET Core and Entity Framework Core. Its current table lists .NET 10 LTS as active through November 2028.

This is a planned deadline, not a new Microsoft announcement. The company warned developers on 29 June and said the two older versions may receive a final update on 10 November if a known critical issue warrants one. That possible patch is not a support extension. Applications will continue to run after support ends, but newly found defects will no longer have the same Microsoft security-fix path.

A newer SDK can build an older target

Microsoft’s upgrade guide separates the SDK used to build an application from the target framework declared in its project file. A global.json file can also pin the SDK used by a solution. Upgrading a developer workstation or CI runner can therefore leave the application target unchanged. A successful build answers whether the current code compiles; it does not answer which major version the published application will use.

The gap can continue after release. Microsoft says a hosting environment that supplies the runtime needs the new runtime installed, while a container’s base-image version must be updated. Framework-dependent applications can benefit from Microsoft Update when their supported runtime is supplied by Windows. Self-contained deployments bundle their runtime, so the application owner is responsible for publishing an updated package. A patched host does not replace the bundled runtime inside an unchanged self-contained application. These distinctions are explicit in Microsoft’s policy and upgrade guidance.

Ask for proof from the running service

The practical unit of work is an application and its owner, not an installed SDK count. A useful migration record should connect five pieces of evidence:

1. Application identity and target. Identify each service, job and vendor product that uses .NET 8 or 9. Record its project target or the supplier’s stated runtime requirement, plus the person accountable for an updated build.
2. Build and package. Check SDK pins, CI configuration, dependencies and the publish mode. Inspect the resulting artefact, not just the source change or the green build badge. For containers, record the runtime base-image version used by the release.
3. Production runtime. Establish what the deployed application actually loads, and whether that runtime comes from the host or travels with the application. A host with .NET 10 installed may still run a self-contained .NET 8 build.
4. Migration test. Retarget and rebuild for a supported release, then test application behaviour, ASP.NET Core and Entity Framework Core dependencies where used, platform compatibility and the rollback path before the production change.
5. Acceptance. Tie the verified runtime and application version to the released artefact and the service running in production. Keep an owner and dated exception for anything that cannot move before 10 November.

Microsoft recommends .NET 10 as the LTS upgrade target, but that does not make every upgrade automatic. Its guide calls out source changes, version pinning, CI and hosting changes. If a supplier controls the application, ask for its supported build and deployment date rather than assuming the organisation can retarget it itself. If a compatibility problem blocks the move, record the unsupported condition and the actual exposure while the supplier and service owner agree a path.

The deadline applies to these two .NET major releases. It does not mean every Microsoft .NET product is ending support, and .NET Framework has a separate policy. The decision before 10 November is concrete: can the team show that the released application, its dependencies and its production runtime all sit on a supported version, or has it only upgraded the tools used to build them?

Sources

• Microsoft .NET and .NET Core support policy, last updated 8 September 2026, checked 29 September.
• Microsoft .NET 8 and .NET 9 end-of-support notice, published 29 June 2026.
• Microsoft guide to upgrading a .NET application, last updated 13 August 2026, checked 29 September.