.NET 8 and 9 End of Support: A Deployment-First Migration Checklist
Microsoft retires .NET 8 and .NET 9 on November 10, 2026, leaving apps without security patches unless they move to .NET 10. A new deployment-first checklist shows how to inventory what is actually running, retarget with minimal risk and prove the migration with artifact-level testing and a rollback rehearsal.
Key points
- Both .NET 8 and .NET 9 exit support on November 10, 2026; .NET 10 LTS is supported through November 2028.
- Inventory deployed artifacts, not just csproj files: containers, jobs, slots, recovery environments and vendor apps all count.
- Framework-dependent and self-contained apps carry runtimes differently, so host runtime lists alone prove nothing.
- Retarget to net10.0 with the same deployment model first; separate AOT or database redesigns into their own releases.
- Validate the published release candidate and replay auth, serialization, persistence and diagnostics cases against it.
- Rehearse rollback before shifting traffic and record artifact, runtime, tests and future patching owner as evidence.
Microsoft ends support for both .NET 8 and .NET 9 on November 10, 2026, so neither release will receive security fixes or servicing after that date, though apps keep running. The guide argues the real scope is every deployed artifact, not every project file: containers, scheduled jobs, slots and vendor apps can still serve old runtimes even when the repository targets net10.0.
Its approach is deployment-first: inventory each service with owner, target framework, hosting model and artifact ID, keep the deployment model unchanged, retarget to net10.0, then test the published release candidate rather than a dev server. Check compatibility through the .NET 10 breaking-change catalog, rehearse rollback including schema compatibility, and close with an evidence record naming who patches the runtime next.
Real-world use
- A team whose repo targets net10.0 but whose production container image still runs an older runtime stage.
- A platform group that must track Windows services, cron jobs and vendor-supplied apps alongside its own web APIs.
- A migration that would break rollback because a new version makes a destructive schema change.
- A release manager who needs an auditable record of tested artifacts and the owner of future runtime patching.
Why it matters
Security fixes stop arriving after that date, so a successful build says nothing about whether a deployed service is still supported; inventorying artifacts and testing the packaged output is what actually closes the gap.