Migrating Logic Apps from Consumption to Standard: Real Lessons and Big Wins – part 1

A Logic App Migration Story

In this series, I’m sharing practical insights and lessons learned from migrating Logic Apps from the Consumption plan to the Standard plan. This post (see part2 & part3) aims to give Azure engineers and solution architects a clear view of the key differences, challenges, and advantages of upgrading. While Microsoft’s documentation provides valuable information, it’s often scattered. Here, I’ll cut through the noise with real-world advice that goes beyond the docs.

Along the way, I’ll include direct links to documentation for quick reference. From managing costs and configuring connectors to improving performance, this series will be a resource for anyone moving to Logic App Standard.

Why Migrate to Logic App Standard?

While there’s plenty of information online about Logic App Standard. Let’s break down the main reasons for migrating to the Standard plan and highlight the core benefits in a nutshell.

• Predictable Costs: With a fixed pricing model, budgeting becomes more straightforward, eliminating the unpredictable costs of the Consumption plan’s pay-as-you-go approach.
• Enhanced Performance: Dedicated resources ensure consistent performance, suggesting faster response times for high-throughput applications.
• Custom Network Configurations: The Standard plan enables integration with Azure Virtual Networks (VNet), allowing Logic Apps to run within a private network for added security.
• Improved Scaling Controls: More scaling offers greater resource governance and stability compared to scaling options available in Consumption.

Built-in vs Managed Connectors: Choosing Wisely

Logic App Standard introduces built-in connectors, different from managed connectors found only in a consumption plan. Here’s a quick comparison:

The key takeaway? Managed connectors offer a broad range of connectivity but at variable performance and additional costs, while built-in connectors are more cost-effective and performance-optimised.

Understand Connector Differences

Built-in connectors are relatively new, and not all connectors available in Consumption have a built-in equivalent in Standard.

Microsoft shares a Roadmap for Built-in connectors for Logic Apps Standard, outlining upcoming connectors and features. I highly recommend following this GitHub repo!

There can be subtle differences between the connectors that are available.For instance, input/output data formats may differ, certain data doesn’t need a base64 string anymore as input and certain properties might require adjustments.

Here’s my recommended approach:

1. Verify if a built-in connector is available for your needs and read the documentation. Sometimes specs are different.
2. Test it to confirm functionality and compatibility with an isolated Proof of concept. Validate things such as functionality, throughput, concurrency, schema definition etc..
3. Implement and follow-up, pay attention to performance, exception handling, logging..

Configuring host.json

For greater control over Logic App Standard behaviour, the host.json file offers customisable settings, which are not available in a logic app Consuption. Here are a few common configurations I use:

• Runtime.Trigger.MaximumRunConcurrency: Sets the maximum concurrent runs for a trigger.
• Runtime.Backend.ApiConnectionOperation.RequestTimeout: Controls request timeout for managed API connectors.
• Runtime.Backend.HttpOperation.RequestTimeout: Sets the timeout for HTTP triggers.
• Runtime.Trigger.MaximumRunConcurrency: Sets the maximum number of concurrent runs that a trigger can start. 

For a full list, refer to Microsoft’s host.json documentation.

Leveraging Application Insights

Logic App Standard integrates natively with Application Insights, providing end-to-end tracing, dependency tracking, and various log levels. I highly recommend enabling this – it streamlines debugging, especially in complex, decoupled microservice architectures.

Enabling Application Insights provides an end-to-end tracking view, including business keys and the ability to monitor logic app tracked properties within Application Insights.

Here’s a sample configuration for host.json:

{
  "version": "2.0",
  "logging": {
    "applicationInsights": {
      "samplingSettings": {
        "isEnabled": true,
        "excludedTypes": "Request",
        "enableDependencyTracking": false,
        "enablePerformanceCountersCollection": false
      }
    },
    "logLevel": {
      "default": "Information",
      "Host.Results": "Error",
      "Function": "Error",
      "Host.Aggregator": "Error"
    }
  },
  "extensionBundle": {
    "id": "Microsoft.Azure.Functions.ExtensionBundle.Workflows",
    "version": "[1.*, 2.0.0)"
  },
  "extensions": {
    "workflow": {
       "settings": {
          "Runtime.ApplicationInsightTelemetryVersion": "v2",
       }
    },
 }

For the latest enhancements, check out this detailed guide on Application Insights for Logic App Standard.

There is also a great video available on this subject explaining everything more in detail:

Stateful vs Stateless Workflows

In Logic App Consumption, workflows are always stateful. This means that every action, step, and result within a workflow run is saved, providing a complete run history and the ability to inspect each execution in detail.

While this is valuable for monitoring, troubleshooting, and supporting complex workflows, it does come with trade-offs: higher storage costs and slightly slower performance due to the time it takes to save each step’s data.

On the other hand, Logic App Standard introduces stateless workflows as an option. Stateless workflows do not store a run history, resulting in faster execution and lower storage costs. This setup is ideal for high-frequency, non-critical processes where historical data isn’t necessary, or for scenarios where minimal latency is crucial.

Here’s a guide I use to to help decide when to go stateful or stateless:

• Stateful Workflows: Best suited for business-critical workflows that require tracking and run history for auditing, troubleshooting, and detailed analytics. Workflows with complex logic or sensitive data may benefit from stateful mode, where every step is traceable.
• Stateless Workflows: Ideal for simple or high-throughput workflows where speed is essential, such as handling non-business-critical data processing or low-priority notifications.

Keep in mind that Application Insights for Logic Apps or Log Analytics for Logic Apps can still be used to enahance observability, regardless of the workflow’s state.

What about Mixing Stateful and Stateless? One of the unique benefits of Logic App Standard is the flexibility to combine stateful and stateless workflows within a single app. This hybrid approach can help optimise performance, cost, and maintainability within your Logic App environment. For instance:

• Business Logic: Set up as stateful to capture all workflow data and provide in-depth analysis when needed.
• Non-Business Logic or Supportive Tasks: Configured as stateless to keep costs low and maintain quick response times.