.NET 8 and .NET 9 both reach end of support on November 10, 2026. After that date Microsoft stops shipping security fixes for either version, and for an application that stays in service past that date, that on its own is reason enough to move to .NET 10. The upgrade does not need an AI feature, or any new feature, to be worth doing.
Some businesses will still want one workflow to come out of the same period measurably better. That is a separate piece of work from the framework move, and it only produces a result anyone can check if the workflow and its current number are chosen before the framework work begins.
Both Support Windows Close on the Same Day
.NET 8 shipped in November 2023 as a Long Term Support release. .NET 9 shipped a year later as a Standard Term Support release. Under the published support policy, both end on November 10, 2026. The dates line up by arithmetic. Standard Term Support now runs for 24 months and Long Term Support for 36, so a 2023 LTS and a 2024 STS finish on the same Patch Tuesday. A team that stayed on .NET 8 because it was the long-term option gets no extra time this cycle. .NET 10 is the current LTS release and is supported until November 14, 2028.
The SDK and the Runtime Move Separately
The SDK installed on the build agents and the target framework written in the project file are two different settings. A newer SDK can build projects that target earlier supported versions, so the .NET 10 SDK can go onto the agents before any project is retargeted. If a repository pins its SDK in global.json, that pin has to be updated at the same time.
What the runtime does on its own depends on how the application is deployed. A framework-dependent app uses a runtime installed on the host, and by default it rolls forward to the newest installed patch of the major version it targets, so a net9.0 app picks up a newer 9.0 patch once that patch is on the server, unless its roll-forward settings say otherwise. It does not cross to a new major version by itself. Installing the .NET 10 runtime on a server leaves a net8.0 app running on .NET 8. A self-contained app carries its own runtime in the published output and changes only when it is rebuilt and republished.
What NETSDK1239 and NETSDK1138 Each Report
Two SDK warnings look relevant to this deadline, and they answer different questions. NETSDK1239 reports that the SDK running the build is end of life, whatever framework the project targets. NETSDK1138 reports that the project's target framework is out of support.
NETSDK1239 is narrower than its message suggests. It is opt-in and runs only when the MSBuild property CheckSdkVulnerabilities is set to true, and Microsoft documents the check as available in .NET 11 Preview 5 and later. A build agent on a released .NET 10 SDK does not have it. Where it is available, the check reads a local cache of SDK release metadata that the CLI refreshes in the background at most once every 24 hours, and it makes no network call during the build, so a new build container that has never populated the cache can stay quiet. Setting CheckSdkVulnerabilities back to false, its default, turns off NETSDK1238, NETSDK1239 and NETSDK1240 together, and NETSDK1239 can also be listed in NoWarn. A clean log from a repository with either setting says nothing about SDK support.
NETSDK1138 does not appear on November 10 either. The .NET release policies say newer supported SDKs start warning about an unsupported target six months after that target's support ends, which means a net8.0 project can build without the warning for roughly half a year after it has stopped receiving fixes. The lifecycle dates are the signal to plan against. An inventory that lists deployed runtimes and build SDKs as separate columns shows where each system actually stands.
One Workflow, Measured Before the Framework Work Starts
If the business wants a visible improvement from the same period, pick one workflow and record its current number before anyone edits a project file. The count can be crude as long as it exists, for example how many invoice exceptions were worked by hand last month, taken from the database this week. Without that before-number, nobody can say afterwards whether the change helped.
If that improvement is an AI feature, it is better scheduled as its own release, after the framework move is finished and stable. Shipping the two together puts open-ended work inside a release with a fixed date, and a problem in either one can hold up both. That separation still has to be checked against the integration itself: if the model call needs a package version that supports only the new target framework, or calls a service that the retarget also changes, that dependency decides which release goes first.
Related Reading
For the deadline and what it changes for each system, read What .NET 8 and .NET 9 End of Support Means for Your Business. For the model call itself, read Adding AI to the .NET Application You Already Run.