What the end of support means
After November 10, 2026, Microsoft provides no security updates or bug fixes for the in-process model, and no technical support for apps that use it. Microsoft has not announced that in-process apps stop running. What changes is that the next vulnerability found in the model stays unpatched, and auditors, insurers and customer security questionnaires start counting the app as unsupported.
The in-process model runs only on .NET 8, and .NET 8's own support ends the same day. Every later .NET version requires the isolated worker model, which supports .NET 10, .NET 9, .NET 8 and .NET Framework 4.8 on Functions 4.x. That makes it one migration, not two: to the isolated worker and to .NET 10 together.
One hosting detail matters. .NET 10 apps can't run on Linux in the Consumption plan, so a Linux Consumption app moves to the Flex Consumption plan, which means a new app rather than a setting change. The Flex Consumption plan doesn't support the in-process model at all. See Microsoft's migration guide and the supported versions.
How to tell which model an app uses
Neither a runtime list nor a target framework shows the model, so the .NET end-of-support checker can date an app's .NET version but not this. Three places do show it:
- The app setting
FUNCTIONS_WORKER_RUNTIME.dotnetmeans in-process;dotnet-isolatedmeans the isolated worker. - The project's package references.
Microsoft.NET.Sdk.Functionsmeans in-process;Microsoft.Azure.Functions.Workermeans the isolated worker. - The app setting
FUNCTIONS_EXTENSION_VERSION.~4is Functions runtime 4.x. Anything lower is runtime 1.x, 2.x or 3.x, which the fixed price doesn't cover.
To list every in-process app in a subscription at once, Microsoft's migration guide includes an Azure PowerShell script.
What changes in a migration
Moving to the isolated worker touches every function, not just the project file. The changes follow a pattern:
- Each function's
[FunctionName]attribute becomes[Function]. - The
ILoggerpassed into each function is replaced by a logger injected through the constructor. - Binding attributes are renamed, and output bindings move to the function's return type.
- The
Startupclass becomesProgram.cs, where the host, dependency injection and configuration are set up. - HTTP functions move to ASP.NET Core integration, with the familiar
HttpRequestandIActionResulttypes. FUNCTIONS_WORKER_RUNTIMEchanges fromdotnettodotnet-isolated.
The .NET Upgrade Assistant makes many of these edits, and we use it. The time goes into checking that every trigger and binding still behaves the same, and into cutting over without breaking whatever calls the app. For the wider .NET 8 and 9 picture, see the .NET 8 and 9 end-of-support guide.
What the migration costs
Every option is a fixed price, agreed before the work starts.
One app on Functions 4.x
$4,000 fixed · live in 1–2 weeks
Up to 10 functions on HTTP, timer, Storage queue, Service Bus or Blob triggers, with their bindings. Moved to the isolated worker on .NET 10, with ASP.NET Core integration for HTTP and dependency injection, logging and app settings carried over. Every function runs locally against test data, then deploys to a staging slot, or a side-by-side app on plans without slots such as Flex Consumption, and is swapped in and watched. The work arrives as a pull request in your repository and deploys into your own Azure tenant.
Start with the assessment
$1,500 fixed · about 1 week
Every function app in your subscriptions, listed with its model, Functions runtime, .NET version, plan, triggers and bindings, Durable Functions use and deployment method, plus a risk list and a fixed price per app. The document is yours whether or not you build with us. If you do, the full $1,500 comes off the build.
A free written review
$0 · reply in 2 business days
Send a list of up to 5 applications and get a short written review back by email: what each one runs on, when its support ends, and what moving it involves. It needs a work email.
Request a free written reviewNot included in the $4,000
- Apps on Functions runtime 1.x, 2.x or 3.x, or tied to libraries that run only on .NET Framework
- Triggers other than HTTP, timer, Storage queue, Service Bus and Blob, such as Event Hubs, Cosmos DB, Event Grid, SignalR or SQL
- Durable Functions
- Custom bindings and extensions
- Apps with more than 10 functions
- Moving a Linux Consumption app to the Flex Consumption plan
- Infrastructure-as-code rewrites
- Package upgrades beyond what .NET 10 needs to compile and run
- Azure consumption costs, which bill to your own subscription
Each is quoted after the written review or the assessment.
How it runs
You work directly with the engineer doing the migration, remotely, in US Central time.
Review or call
Start with the free written review or a free 30-minute call, and tell us which apps are in scope.
Fixed quote
You get a fixed price per app: $4,000 for the common case, or the assessment first for anything larger.
Migrate in a branch
We make the changes in a branch of your repository, run every function locally against test data, and open a pull request.
Test side by side
The migrated app deploys to a staging slot or a side-by-side app and runs against test data before any traffic moves.
Swap and watch
We swap it in, watch it through its first runs, and hand over the source and the notes.
Prefer it in writing?
Send a list of up to 5 applications, function apps or any other .NET applications, and a senior Craftware engineer replies by email within two business days (US Central) with a short written review. It's free and needs a work email.
Request a free written reviewAzure Functions migration: FAQs
-
Do in-process apps stop running on November 10, 2026?
Microsoft has not announced that they stop. What ends on November 10, 2026 is support: no more security updates or bug fixes for the in-process model, and no technical support for apps that use it.
-
Can we move to .NET 10 and stay on the in-process model?
No. The in-process model runs only on .NET 8, whose support ends on the same day, November 10, 2026. Every later .NET version, .NET 10 included, requires the isolated worker model.
-
Our function apps run on Functions 3.x or older. Does the $4,000 apply?
No. The fixed price covers apps already on Functions runtime 4.x. An app on runtime 1.x, 2.x or 3.x, or one tied to libraries that run only on .NET Framework, is a port rather than a migration, so we quote it after the written review or the assessment.
-
Doesn't the .NET Upgrade Assistant do this for free?
It makes many of the code changes, and we use it. The price pays for the rest: bindings and app settings that have to move by hand, running every function against test data, deploying side by side and swapping over once it checks out.
-
What about Durable Functions?
Durable Functions has its own migration path and is not part of the $4,000. We quote it after the written review or the assessment.
-
Do you need access to our Azure subscription?
Only least-privilege access in your own tenant, for the deployment and the swap. The code changes arrive as a pull request in your repository, and the source stays yours.
-
We have a dozen function apps. What does that cost?
Start with the $1,500 assessment. It takes about a week, lists every function app with its model, runtime, plan, triggers and risks, and gives a fixed price per app. The full $1,500 comes off the build if you go ahead with us.
Talk through a Functions migration
A free 30-minute call with a senior Craftware engineer, or a free written review if you'd rather not meet.