Start with what is already working
Before changing target frameworks, record the current isolated-worker runtime, hosting plan, extension packages, and the success behavior that matters in production. Capture what a successful invocation looks like end to end: trigger receipt, binding materialization, downstream call, response or output, and the trace pattern you expect to see. This baseline makes it easier to tell whether a problem comes from the SDK change, the runtime change, or the application code itself.
Use a staging app wired only to test resources. For a queue-triggered function, send one synthetic message to a dedicated test queue and put a unique correlation ID in the payload. Check that the function picked up that message, that the expected test output contains the same ID, and that the invocation logs show what happened. A local startup check or HTTP health endpoint does not exercise that queue trigger or its output binding in Azure.
Separate the package change from the retargeting change
When moving to net11.0, separate the SDK change from the framework retargeting so failures are easier to interpret. Microsoft’s guidance for the isolated worker model points to Azure.Functions.Sdk 1.0.1 or later and an explicit Microsoft.Azure.Functions.Worker reference, with 2.50.0 or later recommended. Keep the extension packages you actually need for your triggers and bindings; do not treat the SDK upgrade as a reason to remove extensions that your app still depends on.
Microsoft announced general availability for C# isolated worker support on November 10, 2026. The same announcement notes that F# is temporarily unavailable, and that Linux Consumption does not support .NET 10 or later. Those constraints matter when choosing the host plan for a canary or migration wave.
Test one trigger before you move the whole app
Run the same exercise on the current build and the .NET 11 candidate, using a fresh correlation ID for each. Write down what success means before testing: for example, the staging input message is processed, a record with that ID appears in the test output, and the invocation log shows completion. Check the destination itself; a successful invocation log alone does not confirm that the output reached the right place.
If you already have defined handling for invalid messages, try one bad payload in staging and verify the behavior you expect, such as rejection or routing to a poison queue. Keep production connections and credentials out of the test. Keep the last working artifact and configuration available so you can restore them if the candidate changes behavior.
Decide hold or proceed based on behavior, not only compilation
Compile success is useful, but it is not enough. Compare the canary’s observed behavior with the baseline you captured before the upgrade. If the trigger fires, the binding resolves, the expected output is produced, and the traces match, you have a stronger case to proceed. If the behavior changes, pause and hold the upgrade until you understand whether the cause is the runtime, an extension package, or your code.
In-process apps need a separate migration path and a separate decision. Do not assume an in-process app can be upgraded the same way as an isolated worker app. For mixed estates, compare behavior side by side, keep the known-good deployable artifact available, and make the migration decision based on observed function behavior in Azure rather than on local startup alone.
Sources
Microsoft announcement: .NET 11 support in Azure Functions
Microsoft Learn: Azure Functions isolated worker guide
