Two runtimes, one deadline

November 10. Microsoft retires .NET 8 and .NET 9 on the same day, the LTS and the STS falling together. After that date: no security fixes, at any severity, for either.

Inventory first. Count every service, container image, lambda, build agent and desktop tool that says net8.0 or net9.0 in its project file. Do not trust the wiki. Grep the repos and walk the registry; the estate always holds more than the spreadsheet says. Last time we ran this exercise for a client we found 41 deployables where the platform team had 28 on record. The other 13 were built by teams that no longer exist.

Then sort the pile into three bins.

1. Actively developed. Retarget to .NET 10, the current LTS, supported to November 2028. For most services this is a one-line change and a test run. Budget a day per service, a week for the ones that pin native dependencies.
2. Frozen but running. These are the risk. Nobody wants to touch them, which is why they must move first, while the people who last touched them are still reachable. Schedule them for October, not January.
3. Dying anyway. If the retirement date lands before mid-2027, consider running out the clock behind a network boundary and saying so in writing. An unpatched runtime is a decision someone senior signs, not a default.

Price it before you argue about it. The upgrade cost is mostly CI time and regression runs. The alternative has a price too: your auditor reads endoflife.date the same as you do, and unsupported runtime findings have a way of landing in board packs in Q1.

One more date while the calendar is open. .NET 10 is the last stop before this happens again in November 2028. If your organisation needed a scramble this year, the fix is not a faster scramble. Pin to the LTS, upgrade in the spring after each release settles, and the November deadlines stop being events.

Thirty-eight days. Enough for the inventory and the first bin if you start Monday. Not enough for a committee. Choose accordingly.