Microsoft announced general availability of .NET 11 in Azure Functions on November 10, 2026. Support uses the isolated worker model and currently covers C#; F# support is temporarily unavailable. Microsoft announcement.
My proposed upgrade pilot would start with the build pipeline, then move through trigger behavior and deployment readiness. A successful framework change needs evidence from the same delivery path the team intends to use in production.
Establish the Hosting and Worker Boundary
Microsoft says support for the in-process model ended on November 10, 2026. Linux Consumption cannot run .NET 10 or later; Microsoft directs those Linux upgrades toward Flex Consumption. Supported versions and hosting restrictions.
I would record the existing worker model, operating system, hosting plan, runtime configuration, and application owner before estimating the work. Give an application that needs a hosting migration its own acceptance record.
Separate the decisions in the change proposal. The reviewer should be able to identify which evidence supports the hosting choice, which supports the worker migration, and which supports the framework upgrade. That makes an unexpected result easier to investigate.
Keep the Build SDK and Worker Runtime Clear
For .NET 11, Microsoft requires Azure.Functions.Sdk 1.0.1 or later as the project SDK. It replaces the Microsoft.Azure.Functions.Worker.Sdk package reference; an explicit Microsoft.Azure.Functions.Worker runtime reference remains necessary. Project SDK changes.
My review would compare the proposed project file with a freshly generated template and explain each retained dependency. Record the selected versions and the reason for each application-specific extension.
Keep the dependency review attached to the change. A future maintainer should be able to distinguish an intentional version choice from an inherited setting that nobody evaluated during the upgrade.
Exercise the Actual Restore Path
The isolated-worker guide says the new SDK generates an extension helper project during restore. A solution or traversal restore does not automatically invoke the required hook; Microsoft documents the remediation under AZFW0108. Restore and generated extension guidance.
That deserves a deliberate CI check. My pilot would begin from a clean agent, use the proposed production build steps, and preserve the restore, discovery, and packaging results alongside the artifact identifier.
Ask a second engineer to reproduce the result from the recorded instructions. Include the build environment and required tooling versions. If the artifact depends on an unrecorded local condition, resolve that before widening the rollout.
Define Trigger-Level Acceptance
I would choose representative functions and write down their expected outcomes before testing. Include a normal invocation, a controlled dependency failure, and the application's established retry or duplicate-delivery scenario where relevant.
For a hypothetical queue processor, the acceptance record might connect an input identifier to the expected business result, observed retry behavior, and diagnostic evidence. Use synthetic data and the application's approved test environment.
Retain observations from the previous release for comparison. Set tolerances for response behavior, error reporting, and operational visibility with the service owner, then investigate differences before interpreting them as acceptable.
Review Container Operations Where Applicable
Microsoft publishes the .NET 11 Functions base image as a chiseled image, without a shell or SSH server. The announcement identifies the chiseled tag and says the corresponding non-chiseled and appservice tags are not published. Container image guidance.
For a containerized application, I would have the operations owner review the existing diagnostic procedure against that image. Rehearse the approved way to collect evidence from a failed startup and document the recovery route.
Preserve the previous artifact and configuration record. Assign the rollout decision to a named owner who can evaluate the pilot evidence and initiate the established recovery procedure if acceptance fails.
Practical Cloud Engineer Takeaway
Inventory the worker model and hosting plan before estimating the upgrade.
Review the new project SDK and retained runtime dependencies.
Verify restore and function discovery on a clean CI agent.
Test representative triggers with recorded expected outcomes.
Rehearse container diagnostics and the recovery procedure.
Who Should Care?
Azure Functions developers, platform engineers, and service owners planning C# runtime upgrades or moving applications away from the in-process model.
Bottom Line
.NET 11 gives Functions teams a new generally available runtime target. The adoption record should demonstrate a repeatable build, compatible hosting, expected application behavior, and a recovery procedure the team can operate.
No function app, hosting plan, package dependency, container image, or Azure deployment was changed for this article.
Sources
Stay radical, stay curious, and keep pushing the boundaries of what is possible in the cloud.
Chriz
Beyond Cloud with Chriz
Comments