How to validate that an Azure Logic Apps Standard application is running on the .NET 10 hosting model

Hi @Gursimran Singh

Thank you for your response.

We have already verified the recommended post-deployment validation by verifying that the Logic App starts successfully, workflows execute correctly, and there are no runtime or startup errors.

However, our primary objective is to understand the migration process itself rather than only validating that the application is healthy.

Based on the Microsoft guidance, our understanding is that the migration from the .NET 6 hosting model to the .NET 10 hosting model is intended to be platform-managed, with minimal or no customer intervention for workflow-only Logic Apps.

However, after comparing our applications before and after the migration, we do not see any significant differences in the application configuration. For example, settings such as:

FUNCTIONS_WORKER_RUNTIME

FUNCTIONS_EXTENSION_VERSION

APP_KIND

WEBSITE_NODE_DEFAULT_VERSION

are the same in both our existing and migrated Logic Apps. Therefore, it is unclear what changes are expected to be performed automatically by Microsoft and what changes, if any, are expected from the customer.

Could you please clarify the following?

1. Could you outline the recommended end-to-end migration steps for customers migrating Azure Logic Apps Standard from the .NET 6 hosting model to the .NET 10 hosting model?

2. What pre-migration checks should customers perform before initiating the migration?

3. What infrastructure, ARM template, application settings, or runtime configuration changes are required from the customer, if any?

4. Our ARM template currently contains:

"netFrameworkVersion": "v6.0"

Should this setting be:

remain unchanged, be removed, or be updated as part of the migration?

5. If Microsoft performs the hosting platform upgrade automatically, what changes should customers expect to see after the migration? Since the application settings appear to remain the same before and after the migration, what are the expected indicators that the migration has actually taken place?

6. Could you also provide the recommended post-migration validation checklist? Specifically, what checks does Microsoft recommend customers perform to confirm that their Logic Apps Standard applications are running on the intended .NET 10 hosting model?

Our goal is to create a standardized migration guide, including the required customer actions, the changes performed automatically by Microsoft, and the recommended validation process after the migration.

Thank you.

Hi @Siddhardha Narnindi (DHL IT Services) ,

Thank you for your response

Officially, I have not found a documented Microsoft method to verify the migration. However, there are a few practical checks that may help investigate whether the hosting model transition has occurred.

1. Check Kudu Environment Variables

Request a screenshot of Kudu** → **Environment and compare the environment before and after migration.

Review settings such as:

Plain Text

LOGICAPP_INPROC_REDIRECT

FUNCTIONS_WORKER_RUNTIME

FUNCTIONS_EXTENSION_VERSION

Show more lines

For example, if the migration guidance references LOGICAPP_INPROC_REDIRECT and that setting is no longer present, it could indicate that the application is no longer pinned to the previous hosting model.

2. Review Processes in Kudu

Navigate to:

Plain Text

Kudu → Process Explorer

Review the processes that are running after the migration.

If the application has moved from an in-process hosting model to an out-of-process hosting model, there may be differences in the process architecture. However, I have not found Microsoft documentation that defines specific process names or process structures that can be used as an official validation method.

3. Examine Function Host Startup Logs

Review startup logs in:

• Log Stream
• Application Insights
• Kudu logs

Look for entries containing terms such as:

worker

hosting

out-of-proc

host started

In some cases, startup logs can provide clues about the hosting behavior and runtime initialization.

4. Compare ARM Template Configuration

A useful validation approach is to compare the Logic App configuration before and after migration.

Review properties such as:

JSON

siteConfig

appSettings

kind

linuxFxVersion

netFrameworkVersion

If Microsoft describes the migration as platform-managed and no customer-visible configuration changes are observed, it may indicate that the migration occurred at the platform/runtime layer rather than through changes exposed in the Logic App configuration.