Clear your November calendar. .NET 8 and .NET 9 both reach end of support on November 10, and PowerShell 7.4 dies the same day. After that date there are no more security fixes, no servicing updates, and no support tickets honored for any of the three. Microsoft published the Azure Functions side of the notice only this week, which leaves about seven weeks of runway for what is, for some teams, a multi-week migration.
Why one day kills three runtimes
The shared deadline is not a coincidence, it is arithmetic. .NET 8 is an LTS release with a 36-month window that started in November 2023. .NET 9 is an STS release, and starting with .NET 9 Microsoft extended standard-term support from 18 to 24 months, which lands it on the exact same end date as .NET 8. PowerShell 7.4 is an LTS release built on .NET 8, so its retirement tracks the runtime underneath it. One Patch Tuesday, three casualties.
The math that stings: .NET 8 users have to skip a version entirely. The upgrade target is .NET 10, the current LTS released in November 2025, supported through November 2028 per the official .NET support policy.
What Azure Functions users need to know
The Azure Functions notice carries the usual but important caveat: function apps on retired versions keep running, they just stop receiving security updates. Microsoft’s language support policy also warns that unsupported runtime versions can face scale limits on consumption plans, so a function app that “still works” may quietly lose capacity under load.
Two migration wrinkles make this more than a version bump for some apps. C# function apps still on the in-process model must move to the isolated worker model before they can target .NET 10, and that refactor is a bigger job than retargeting a csproj file. Apps on Linux Consumption must move to Flex Consumption first, because Linux Consumption will not host the new runtimes. Microsoft’s language stack update guide covers the steps for both.
PowerShell function apps have it easier: retarget to PowerShell 7.6, the LTS built on .NET 10 that shipped in March and is supported until November 2028.
What you get for the trouble
.NET 10 is not just a version number you must adopt. The release brings JIT and NativeAOT improvements including Arm64 SVE support, post-quantum cryptography through Windows CNG with ML-DSA and ML-KEM, passkey and WebAuthn support in ASP.NET Core Identity, OpenAPI 3.1 support, and automatic memory pool eviction. None of these are reasons to upgrade on their own, but they soften the landing, and the post-quantum crypto work is worth a look if your compliance team has started asking about it.
Find out what you are actually running
Before planning anything, establish the blast radius. For Functions, the Azure CLI answers quickly: az functionapp list with a query on name and functionAppConfig or siteConfig exposes the PowerShell version per app, and C# apps show their target framework in the csproj or in the FUNCTIONS_WORKER_RUNTIME related settings. Do not forget the apps nobody remembers, the ones with a deployment slot from 2024 and a former owner who left the company. Those are the ones that will be discovered in week six.
Outside Functions, grep for TargetFramework across your repos and check your container base images. The mcr.microsoft.com/dotnet/sdk:8.0 and 9.0 tags will keep existing on Docker Hub, but an image tag is not a support contract. Anything still referencing those tags after November 10 is building on an unsupported runtime whether the pipeline is green or not.
The part nobody reads until it hurts
“Your apps keep running but stop getting security updates” is the most dangerous sentence in any end-of-support notice. It reads as permission to procrastinate, and serverless teams are extra vulnerable to that reading because Azure handles the OS patching, so it is easy to assume Microsoft handles everything. It does not. The runtime inside your function app is your dependency, and a functions app on .NET 8 in December will be carrying every CVE disclosed after November 10 with no fix coming.
The practical order of operations: audit your function apps now and note the worker runtime and target framework on each. Migrate in-process C# apps to the isolated worker model first, since that is the long pole. Then retarget to .NET 10 or PowerShell 7.6. Move Linux Consumption apps to Flex Consumption along the way. And do not stop at Functions, because the runtime end of support is global: App Service apps, containers, and VMs on .NET 8 or 9 need the same treatment.
One more trap worth naming: this deadline lands in the middle of the holiday build freeze season for a lot of shops. If your organization locks production changes from mid-December through early January, the real runway is not seven weeks, it is whatever is left before the freeze starts. Book the migration window now, before the change advisory board calendar fills up with December deploy restrictions.
Seven weeks is enough time for a well-prepared team and not enough for one that discovers three in-process apps in week six. Start with the audit. It takes an afternoon.