Quick answer. As of September 2026, Microsoft ends support for .NET 8, .NET 9 and the Azure Functions in-process model on November 10, 2026, so move in-process function apps to the isolated worker model first, because that model is the only way past .NET 8, and move every .NET 8 and .NET 9 application to .NET 10, the current long-term support release, supported to November 14, 2028. The applications will keep running after that date, but the Microsoft .NET Blog says no new security updates will be issued for either version and that “Staying on an unsupported version means you are exposed to security vulnerabilities that will not be patched.” For a function app, Microsoft’s migration guide makes the move a code migration plus two changes in Azure that each restart the app, and says “When feasible, use a staging slot during the migration.”
When a security scan or an Azure notice lists applications on .NET 8 or .NET 9 and function apps on the in-process model, all against the same November 10, 2026 date, the list does not say which items are a version change and which are a code migration. That difference sets the funding order. This guide sets out what Microsoft’s own pages, read on 2026-09-24, say about each retirement, what keeps running after the date, why the in-process function apps go first, and what to fund. Applications still on .NET Framework are a different decision, covered in the counter-case below.
Three Retirements Land on One Date
If your team has planned the runtime and the function apps as separate projects with separate deadlines, the dates say otherwise. Microsoft’s .NET and .NET Core Support Policy page, last updated September 8, 2026, lists .NET 10 as an LTS release in Active support until November 14, 2028, .NET 9 as an STS release in Maintenance until November 10, 2026, and .NET 8 as an LTS release in Maintenance until November 10, 2026. The Microsoft .NET Blog post .NET 8 and .NET 9 will reach End of Support on November 10, 2026 says “.NET 8 and .NET 9 will reach end of support on November 10, 2026. After that date, Microsoft will no longer provide servicing updates, security fixes, or technical support for these versions.”
The same post explains why .NET 9, a Standard Term Support (STS) release, ends on the same day as .NET 8, a Long Term Support (LTS) release, and says “As we announced, STS releases now get 24 months of support instead of 18. That puts .NET 9 end of support on the same day: November 10, 2026.” Microsoft’s Supported languages in Azure Functions page records the change in its own words: “.NET 9 previously had an expected end-of-support date of May 12, 2026. During the .NET 9 service window, the .NET team extended support for STS versions to 24 months, starting with .NET 9.” Plan on November 10, 2026 for .NET 9, not the earlier date.
Azure Functions adds the third retirement, the execution model. Microsoft’s Ending Support in 2026 page lists “Azure Functions In-process model end of support” with a retirement date of November 10, 2026. Microsoft’s Differences between the isolated worker model and the in-process model for .NET on Azure Functions says “Support will end for the in-process model on November 10, 2026. We highly recommend that you migrate your apps to the isolated worker model for full support.” Microsoft’s Update language stack versions in Azure Functions page states the deadline plainly: “If your function app uses the in-process model, you must migrate from the in-process model to the isolated worker model before November 10, 2026.”
Of the releases in that support table, .NET 10 is the one supported target that outlives the date.
What Keeps Running After November 10, and What Stops
If someone on the team says the applications will still run, they are right, and that is the risk rather than the reassurance. The Microsoft .NET Blog says “Applications built on .NET 8 or .NET 9 will continue to run. No new security updates will be issued for either version.” and “Staying on an unsupported version means you are exposed to security vulnerabilities that will not be patched.” On the date itself, the post says “November 10th is a Patch Tuesday release day. .NET 8 and .NET 9 may each receive one final update on that day if there is a known critical issue.”
For function apps, Microsoft’s Azure Functions language stack support policy says “After the language end-of-life date, function apps that use retired language versions can still be created and deployed, and they continue to run on the platform. However, these apps aren’t eligible for new features, security patches, and performance optimizations until after you upgrade them to a supported language version.” The same policy adds “Further, if required, in certain cases we will limit the number of instances allocated to these apps including limit scaling to 1 instance.”
Microsoft’s Language runtime support policy for Azure App Service covers web apps on Azure App Service and says “After community support for a language reaches the end of support, applications that use the language continue to run unchanged. However, App Service can’t provide security patches or related customer support for that runtime version past its end-of-support date.”
Treat the fact that an application still runs as the reason to plan, not the reason to wait.
What to Show a Security Review or Risk Committee
If a security review or a risk committee asks how the estate stands against the date, show them evidence, not intent. Microsoft’s support policy sets the condition for servicing in one sentence: “Within a release’s support lifecycle, systems must remain current on released patch updates.” Past the end of support, the Microsoft .NET Blog says no new security updates will be issued. The evidence that answers both statements is an inventory and a record:
- A dated inventory of every application and function app, with its .NET version, its execution model, its hosting plan and its owner.
- The funded order of the moves, and the target date for each application.
- For any application still on .NET 8 or .NET 9 after November 10, 2026, a written risk decision with a named owner and an exit date.
Why the In-Process Function Apps Go First
If a function app runs on the in-process model, raising its .NET version is not an option. Microsoft’s Differences between the isolated worker model and the in-process model for .NET on Azure Functions describes the in-process model this way: “Your function code runs in the same process as the Functions host process. Supports only Long Term Support (LTS) versions of .NET.” Its comparison table gives the in-process model’s supported versions as “Long Term Support (LTS) versions, ending with .NET 8”. Microsoft’s Supported languages in Azure Functions page says “The in-process model currently only supports .NET 8. To be able to update your function app to use a later .NET version, you must migrate to the isolated worker model.”
So an in-process function app that misses November 10, 2026 sits on an unsupported .NET version and an unsupported execution model at once, and the way out is a code migration, not a version change. That is why these apps are funded first: each one needs a code migration before it can reach a supported .NET version at all.
The migration also brings a benefit Microsoft names. Microsoft’s Guide for running C# Azure Functions in the isolated worker model lists among its benefits “Fewer conflicts: Because your functions run in a separate process, assemblies used in your app don’t conflict with different versions of the same assemblies used by the host process.”
Check the host version before the code. Microsoft’s Migrate C# apps from the in-process model to the isolated worker model guide says “This guide assumes that your app is running on version 4.x of the Functions runtime.” Microsoft’s Compare Azure Functions runtime versions page says “Azure Functions currently supports only version 4.x of the runtime host.” and “Support ended for version 1.x of the Azure Functions runtime on September 14, 2026.” An app on an older host has that upgrade to make as well.
How a Function App Moves, and Where It Breaks in Production
If the cutover is treated as a single deployment, the app can fail between its two steps. Microsoft’s migration guide names the target first: “If your app and its dependencies can run on .NET, target .NET 10. If your app depends on libraries or APIs available only in .NET Framework, target .NET Framework 4.8.”
The guide then describes two changes in Azure that it says to plan together: setting FUNCTIONS_WORKER_RUNTIME to dotnet-isolated, and publishing the migrated isolated worker project. Microsoft’s guide says “Each change restarts the app. After you complete the first change, the deployed code and configured runtime don’t match, which causes a runtime/payload mismatch error (AZFD0013) until you complete the second change.” Its answer is “When feasible, use a staging slot during the migration.” For the pipelines, Microsoft’s guide says “If you have any automated infrastructure provisioning such as a CI/CD pipeline, ensure that the automations are also updated to keep FUNCTIONS_WORKER_RUNTIME set to dotnet-isolated and to target the correct .NET version.”
Check the hosting plan before choosing .NET 10. Microsoft’s Differences between the isolated worker model and the in-process model for .NET on Azure Functions says “You can’t run .NET 10 apps on Linux in the Consumption plan. To run on Linux, you should instead use the Flex Consumption plan.” Microsoft’s Supported languages in Azure Functions page says “.NET 9 is the last .NET version supported for Linux Consumption plan apps. Newer .NET versions aren’t added to Linux Consumption.” and “The option to host function apps on Linux in a Consumption plan is retiring on 30 September 2028.” A function app on Linux in the Consumption plan that moves to .NET 10 therefore changes its hosting plan, and an in-process app changes its execution model as well. If that move reopens where the app should run at all, Azure Architecture for Microsoft-Centric Enterprises covers that choice.
The Rest of the Portfolio: .NET 8 and .NET 9 Applications to .NET 10
If the function apps are handled and the web applications and services are not, the portfolio is still exposed on the same date. Microsoft’s .NET Blog says “We recommend upgrading to .NET 10, which is an LTS release supported through November 2028.” Microsoft’s .NET and .NET Core Support Policy page sets the lengths behind that choice and says “LTS releases get free support and patches for three years.” Microsoft’s documentation adds “STS releases get free support and patches for two years.”
This guide’s recommended order, which is a planning rule and not a Microsoft statement:
- Start with an inventory of every application by .NET version and by who can change it: built in-house, built and supported by an outside builder, or a vendor’s product.
- Fund the in-process function apps first.
- Then move internet-facing applications and applications that hold sensitive data, before internal ones.
- For a vendor’s product, ask the vendor for a .NET 10 build, which is the Microsoft .NET Blog’s own advice for such apps.
- Name an owner for keeping each application on a supported runtime after the move, and record .NET 10’s end of support, November 14, 2028 in Microsoft’s support policy, as that owner’s next date.
Staying current inside the release matters as much as the release. Microsoft’s support policy says “Within a release’s support lifecycle, systems must remain current on released patch updates.”
When This Is Not Your Answer, or Not Yet
If an application does not fit the pattern above, forcing it into the plan creates rework:
- If the application still runs on .NET Framework, it is not a version bump. Which path it takes is covered in Application Modernization Decision Framework: Six Paths.
- If the application will be retired soon, a move is not always worth the spend. A dated retirement decision with a named owner is a legitimate answer, provided it records the risk the Microsoft .NET Blog states: no new security updates after the date, and exposure “to security vulnerabilities that will not be patched.”
- If a function app depends on libraries or APIs available only in .NET Framework, Microsoft’s migration guide says to target .NET Framework 4.8 on the isolated worker model, not .NET 10.
What to Ask of Whoever Does the Work
If you bring in outside help, judge the plan against these items:
- A written inventory of applications and function apps by .NET version, execution model, hosting plan and owner.
- A staging-slot plan for every function app, so the mismatch between the two changes never reaches production.
- Pipeline and infrastructure-as-code updates in the same change as the code.
- A test plan for each application against .NET 10.
- Senior, US-based people doing the work.
- A plain statement of who keeps each application on a supported runtime after the project closes, and whether that is an ongoing service at all.
How i3solutions Answers
If the portfolio needs the work done as well as planned, i3solutions builds custom .NET applications that run on Azure App Service and Azure Functions, described in Custom .NET Application Development Services for Enterprises. i3solutions also provides senior .NET specialists for migration and modernization work, on a project or embedded in your team. Delivery is senior and US-based.
For the upgrade itself, the work is a project. An i3solutions engagement does not produce managed-service ownership, a replacement for the internal team, open-ended scope expansion, or vendor lock-in.
Where i3solutions built or modernized an application, keeping it on a supported runtime is part of the operation, support and enhancement it provides as application managed services, described in Application Managed Services for Custom Microsoft Applications.
The wider practice is Custom Application Development Services for Enterprise Performance.
Key Takeaways
- Microsoft ends support for .NET 8, .NET 9 and the Azure Functions in-process model on November 10, 2026.
- Microsoft’s support policy lists .NET 10 as the LTS release in Active support until November 14, 2028.
- Microsoft says the in-process model currently only supports .NET 8, so in-process function apps migrate to the isolated worker model before they can reach .NET 10.
- Microsoft says applications on .NET 8 or .NET 9 will continue to run after the date, with no new security updates.
- On Microsoft Learn, .NET 10 apps cannot run on Linux in the Consumption plan; the Flex Consumption plan is Microsoft’s route on Linux.
- Fund the in-process function apps first, then internet-facing and sensitive-data applications, and name an owner for each application after the move.
Frequently Asked Questions
When does .NET 8 support end?
Microsoft’s .NET Blog says “.NET 8 and .NET 9 will reach end of support on November 10, 2026. After that date, Microsoft will no longer provide servicing updates, security fixes, or technical support for these versions.”
Why does .NET 9 end on the same day as .NET 8?
Microsoft’s blog post says “As we announced, STS releases now get 24 months of support instead of 18.” The post adds “That puts .NET 9 end of support on the same day: November 10, 2026.” Microsoft Learn says “.NET 9 previously had an expected end-of-support date of May 12, 2026.” Microsoft Learn adds “During the .NET 9 service window, the .NET team extended support for STS versions to 24 months, starting with .NET 9.”
Will our .NET 8 applications stop working on November 10, 2026?
No, but they will get no new security updates. Microsoft’s .NET Blog says “Applications built on .NET 8 or .NET 9 will continue to run. No new security updates will be issued for either version.” For function apps, Microsoft Learn says retired versions “continue to run on the platform” but “aren’t eligible for new features, security patches, and performance optimizations until after you upgrade them to a supported language version.”
Can an in-process Azure Functions app run on .NET 10?
No. Microsoft Learn says “The in-process model currently only supports .NET 8. To be able to update your function app to use a later .NET version, you must migrate to the isolated worker model.”
Which .NET version should we upgrade to?
Microsoft’s .NET Blog says “We recommend upgrading to .NET 10, which is an LTS release supported through November 2028.” For function apps, Microsoft Learn says “If your app and its dependencies can run on .NET, target .NET 10. If your app depends on libraries or APIs available only in .NET Framework, target .NET Framework 4.8.”
Planning the Decision
If your portfolio needs a runtime and execution-model inventory, a funded move order and a cutover plan for each function app before November 10, 2026, the next step is a conversation about your applications.
