Many organizations built serverless applications on Azure Functions between 2020 and 2024. A common pattern was a C# function app running in the in-process model on .NET 6 or .NET 8, triggered by queues, timers, or HTTP calls, handling integrations, data processing, and background jobs. Often an Azure cloud consultant designed and delivered these apps, handed them over, and moved on to the next project.
Those apps now face a hard date. Microsoft ends support for the in-process model on November 10, 2026. On the same day, .NET 8 and .NET 9 reach end of support. Function apps that have not moved to the isolated worker model on a supported .NET version will run on an unsupported combination, without security fixes or platform support.
The pattern repeats. Azure retires runtimes, SDKs, API versions, and services every year. Builds delivered only a few years ago regularly become unsupported. The question every organization should ask is who is responsible for noticing and funding that work. In most consulting contracts, the answer is nobody.
What Retires on November 10, 2026
Microsoft's guide to migrating to the isolated worker model states that support for the in-process model ends on November 10, 2026, and directs customers to migrate their apps to the isolated worker model. It recommends targeting .NET 10 where the app and its dependencies can run on modern .NET, or .NET Framework 4.8 where they depend on Framework-only libraries.
The .NET support policy lists November 10, 2026 as the end of support for both .NET 8, a long-term support release, and .NET 9, a standard-term release. Function apps on either version need a framework upgrade as well as a model change.
What the Migration Involves
The migration is well documented, but it is not a configuration switch. Microsoft's guide describes changes across the project:
Project file: New SDK, new target framework, and replacement of in-process packages with isolated worker packages.
Program.cs: A new startup file replaces any `FunctionsStartup` class, with dependency injection and Application Insights configured there.
Function signatures: The `FunctionName` attribute becomes `Function`, logging moves from method parameters to injected loggers, and binding attributes change names and parameters.
Bindings: Extension packages for storage, Service Bus, Event Hubs, Cosmos DB, Durable Functions, and others must be replaced with their isolated worker versions, sometimes with breaking changes in `host.json`.
HTTP functions: Synchronous stream reads and writes must become asynchronous under ASP.NET Core integration.
Serialization: The isolated model uses System.Text.Json by default, which ignores Newtonsoft.Json attributes and can silently change how payloads bind.
Deployment: The `FUNCTIONS_WORKER_RUNTIME` setting must change to `dotnet-isolated` together with the new code, ideally through a staging slot swap to avoid errors in production.
The .NET Upgrade Assistant can automate many of these changes, but each app still needs testing, especially around bindings, serialization, and logging.
Why Retirement Work Falls Through the Cracks
Consulting engagements are usually scoped around delivery. The statement of work covers design, build, test, and deployment, followed by a short warranty or hypercare period. After that, the app belongs to the client's operations team, who may not have the skills or time to track platform changes.
Azure publishes retirement notices, and service health alerts flag affected resources. But notices arrive continuously and cover hundreds of services. Without a named owner who maps notices to the organization's estate, they are easy to miss. When the deadline approaches, the team that built the app may be gone, and the knowledge needed to migrate it safely has to be rebuilt.
The Cost of Missing a Retirement
Running unsupported runtimes and models carries real risk. Security vulnerabilities discovered after end of support will not be patched. Platform updates may eventually break unsupported configurations. Support cases may be declined. Auditors reviewing SOC 2, ISO 27001, PCI DSS, or HIPAA controls often flag unsupported software, which leads to findings and remediation plans under time pressure.
Late migrations also cost more. Work done in a rush, by a team unfamiliar with the code, takes longer and carries more risk than work planned months ahead with the original design documentation.
What to Buy From Azure Cloud Consulting Services
Organizations can close the gap by changing what they buy from Azure cloud consulting services. Alongside new builds, contract for:
Estate inventory: a maintained list of Azure resources, runtimes, SDK versions, API versions, and the applications that depend on them.
Retirement monitoring: regular review of Azure retirement notices and runtime lifecycle dates, mapped to the inventory.
Impact assessment: for each upcoming retirement, a list of affected apps, the work required, and an effort estimate.
Funding plan: a forward budget for retirement work, typically for the next 12 to 18 months, so the money is available before deadlines.
Delivery: planned migrations, tested in staging and completed well before the retirement date.
Documentation: updated architecture and runbooks after each change, so knowledge stays current.
These services can sit within a managed services agreement or a retained advisory arrangement. Azure cloud consulting services structured this way cost far less than emergency migrations, and the key is that someone is accountable.
Using Azure's Own Tools to Find Affected Resources
Azure provides several tools that make inventory and monitoring easier. Azure Service Health shows retirement notices for services in use, filtered to the subscriptions affected. Azure Advisor raises recommendations for some retirements and upgrades. Azure Resource Graph queries can list function apps by runtime setting and framework version across many subscriptions at once, and Microsoft's migration guide includes a PowerShell script for finding in-process apps.
These tools help, but they need someone to use them consistently. Notices must be read, matched to the applications and owners behind each resource, and turned into planned work. A consultant who runs these queries monthly, maintains the mapping from resources to applications, and reports upcoming retirements to application owners turns raw alerts into a manageable plan.
Who Pays for Retirement Work
Retirement work often triggers awkward commercial conversations. The original partner may argue that the build was correct when delivered and that migration is new work. The client may feel that a recently delivered app should not need rework so soon. Both positions are reasonable, which is why the question should be settled in the contract.
New statements of work can state the runtime versions and support dates used, require the partner to flag any known retirements within a defined horizon at delivery, and set out how future retirement work will be priced, whether as part of a managed service, a retained budget, or change requests at agreed rates. Clarity up front avoids disputes later and gives finance a predictable line for platform maintenance.
A Representative Estate
Consider a retailer whose Azure estate includes 45 function apps built over four years by two different partners. An inventory finds that 30 run in-process on .NET 8, eight run on the isolated model with .NET 8, and seven run on the isolated model with .NET 10.
The retirement assessment shows that 30 apps need both a model migration and a framework upgrade, and eight need only a framework upgrade. Six of the in-process apps use Durable Functions and Service Bus bindings with custom serialization, which makes them the riskiest. The team schedules those first, tests them in staging slots with production-like messages, and finishes the simpler apps in batches. A forward plan also flags two storage SDK retirements and an API version change due the following year.
Without the inventory, the retailer would have learned of the deadline from a service health alert weeks before the date, with no budget and no partner engaged.
What to Ask an Azure Cloud Consultant
When selecting an Azure cloud consultant or reviewing an existing contract, ask:
How do you track Azure retirements and runtime lifecycle dates for client estates?
Can you produce an inventory of the client's runtimes, SDKs, and API versions, and a list of retirements affecting the estate in the next 18 months?
How do you estimate and budget retirement work?
Who on your team is accountable for flagging upcoming changes?
How do you document builds so another team can migrate them later?
Azure consulting partners that answer with specific processes and examples are offering more than project delivery. Azure consulting firms that answer only with build capabilities may leave the long-term risk with you.
Design for the Next Retirement
Retirements will keep coming, so new builds should be designed with them in mind. Prefer long-term support runtimes, keep dependencies current, use infrastructure as code so environments can be rebuilt on new versions, maintain automated tests that make upgrades safer, and document architecture decisions. Azure cloud consulting that builds these habits into every project reduces the cost of each future retirement. A simple test for any new build is whether a different team could upgrade it two years later using only the repository, the pipeline, and the documentation. If the answer is yes, the next retirement will be routine. If the answer depends on one engineer's memory, it will not be. Ask partners to demonstrate this at handover by walking the client's team through an upgrade rehearsal in a non-production environment, so knowledge transfers while the original builders are still available to answer questions.
Practical Steps Before November 10
If your organization runs .NET function apps, act now:
Run Microsoft's PowerShell script or Azure Resource Graph queries to list function apps using the in-process model.
Check the .NET version for every function app and other .NET workloads.
Prioritize apps by business criticality and migration complexity.
Migrate the highest-risk apps first, using staging slots and thorough testing.
Plan the remaining work with clear owners and dates, even if some will finish after the deadline.
The November 10, 2026 end of support for the Azure Functions in-process model and .NET 8 shows how quickly recent builds can become unsupported. Contract your Azure cloud consultant to maintain an inventory, monitor retirements, estimate and fund the work, and deliver migrations before deadlines, as well as building new solutions. Damco provides Azure consulting services that include retirement tracking and planned modernization for client estates. The next retirement notice is already scheduled, and the organizations that see it early will spend the least to meet it.
