Production workflows can’t afford to break. They are often responsible for moving data between core systems in near real time, and a failure can result in orders not being fulfilled, customer record isn’t updated, or downstream systems operating on incomplete or incorrect data. This can quickly lead to operational disruption and overtime a loss of trust in the integration platform itself.
In many Azure environments, Logic Apps sit at the centre of the integration layer. They connect SaaS platforms, orchestrate workflows, and bridge legacy systems with cloud services. As integration estates mature, teams start needing more structure around how solutions are built and operated, including stronger DevOps practices, consistent deployments across environments, and greater control over security and networking.
The Consumption model can be easily adopted by teams building initial integration solutions because it offers rapid development, simple deployment, and low operational overhead. However, as environments grow, teams often begin to encounter operational friction particularly around DevOps maturity, environment consistency, networking control, and long-term architectural alignment. That’s where the Standard model becomes the natural next step for many integration platforms.
Standard enables a more application centric integration model, with stronger alignment to modern DevOps practices, improved environment consistency, and greater control over runtime behaviour. It runs on a single tenant runtime built on the Azure Functions extensibility model and hosted on Azure App Service, introducing file-based workflows, local development capabilities, and consolidated hosting. The real challenge isn’t deciding to adopt Standard but executing a safe migration.
Rebuilding workflows from scratch isn’t realistic, as they can house many years of incremental changes, edge-case handling, and system specific logic accumulated in response to real operational needs. Microsoft’s Clone to Standard capability helps accelerate the initial move from Consumption to Standard, but it’s not a one-click upgrade. Connector behaviour can differ, managed identities often need to be re-established, and networking and hosting models change as part of the transition. In Scenarios that rely on B2B or XML processing, integration account artefacts must be separately reviewed and re-implemented, as they are not migrated automatically. Without careful validation and testing, these differences can introduce subtle failures that are difficult to diagnose once the workflows are running.
In this post, I’ll break down what changes in Standard, how migration works in practice, where the Clone tooling genuinely helps, and what teams need to plan for before making the move.
What is Logic Apps Standard?
Logic Apps Standard is the single-tenant hosting model for Azure Logic Apps. Unlike the multi-tenant Consumption model, Standard runs on dedicated compute built on Azure App Service.
This shift changes more than pricing — it changes how integrations are built and operated.
Standard introduces:
- File-based workflows stored within a project structure
- Built-in (in-process) and managed connector support
- Consolidated hosting of multiple workflows in one Logic App resource
In short, Standard moves Logic Apps closer to an application-centric model rather than a per-workflow service model.
Why Organisations Move from Consumption to Standard
Teams rarely migrate because it’s fashionable. They migrate because integration platforms evolve and operational demands increase.
- Performance and predictability – Consumption runs in a multi-tenant environment. While it scales automatically, performance variance and throttling can occur under heavy regional load. Standard runs on dedicated compute via an App Service plan, providing more predictable throughput and scaling control.
- Enterprise deployment maturity – In Consumption, each workflow is deployed as a separate resource. In Standard, workflows are packaged and deployed as part of a single application artifact, which aligns more naturally with modern CI/CD pipelines and source-controlled project structures.
- Expanded runtime capabilities – Standard introduces several capabilities that are difficult or impossible to implement in Consumption without additional services. Features such as the built-in Data Mapper, inline code execution, improved data transformation tooling, and deeper runtime extensibility allow teams to implement more complex integration logic directly within the workflow runtime, reducing the need for external services or custom middleware.
- Networking and security control – Standard supports VNET integration and private networking without requiring Integration Service Environments (ISE), which historically made network isolation expensive in the Consumption model.
- Cost model considerations – Consumption follows a per-action billing model. Standard shifts toward compute-based hosting (Workflow Standard, App Service, or Elastic Premium plans). At scale, this can simplify cost forecasting and, in some scenarios, reduce overall spend — but it requires modelling.
- Future Support – Microsoft focus seems to be shifting towards the Standard runtime, with many new capabilities being delivered there first, making it the strategic direction for modern Logic Apps deployments.
What Changes and Improves in Standard
Migrating to Standard involves more than a hosting change — it introduces a different operational model for running integrations.
When moving to Standard, teams must account for:
- Workflow definitions becoming part of a file-based project
- Differences between built-in and managed connectors
- Runtime and configuration files such as host.json, connections.json, and local.settings.json becoming part of the project structure
- Hosting, scaling, and resource allocation behaviour tied to the underlying plan
- Responsibility for managing the underlying hosting resources such as compute plans, application configuration, and storage accounts
- The ability to mix stateless and stateful workflows
- Workflows sharing compute and storage resources within the same Logic App runtime instance
These changes affect how you structure environments, manage configuration, and design deployment pipelines.
How Migration Works in Practice
A structured migration approach typically includes the following steps to help organisations transition safely while taking advantage of Standard’s expanded capabilities:
- Assess existing workflows
Identify triggers, connectors, integration account usage, and custom dependencies. Also review workflow state requirements, as stateless and stateful workflows differ in durability, run history visibility, and execution limits. - Review connector compatibility
Not all connectors behave identically in Standard.Pay close attention to built-in vs managed connector behaviour, authentication models, and connection configuration. - Evaluate configuration and parameterisation
Ensure environment-specific settings (URLs, secrets, identities) are externalised properly. - Design your Standard environment structure
Decide how workflows should be grouped within projects and how hosting plans will beallocated. - Execute migration with automation plus validation
Use tooling whereappropriate, but plan for manual review and refactoring.
Using the Clone to Standard Tool: What It Does — and What It Doesn’t
Microsoft’s Clone to Standard capability accelerates migration by converting a Consumption Logic App into a Standard project structure.
It can:
- Convert existing workflow definitions into a Standard project structure
- Create the appropriate project scaffolding
- Reduce baseline migration effort
It does not:
- Resolve connector behavioural differences
- Automatically optimise project structure
- Redesign networking configuration
- Refactor integration account dependencies
- Validate runtime performance assumptions
- Provision the underlying infrastructure, this requires manual implementation as a pre-requisite.
It should be viewed as a starting point rather than a complete migration strategy. For details on pre-requisites and limitations Microsoft have a detailed page with further details: https://learn.microsoft.com/en-us/azure/logic-apps/clone-consumption-logic-app-to-standard-workflow
When to Use (and Not Use) the Clone Tool
Use it when:
- You need to migrate multiple similar workflows
- Your workflows are relatively straightforward
- You want to accelerate baseline conversion
Avoid relying solely on it when:
- Workflows are highly complex or tightly coupled
- Significant architectural redesign is required
- Networking or identity models are changing substantially
Common Migration Pitfalls
- Treating the migration as a simple export/import exercise
- Underestimating connector behaviour differences between built-in and managed connectors
- Migrating large numbers of workflows into a single Standard runtime without considering resource contention
Preparing for a Smooth Migration
Successful migrations typically prioritise repeatability and consistency.
- Establish Standard project templates and folder structures early
- Define naming and grouping conventions
- Build CI/CD pipelines before migrating at scale
- Leverage the Standard workflow testing framework to capture existing behaviour and validate that migrated workflows execute consistently
- Create internal patterns for connections and parameter management
- Test performance assumptions under load
Treat migration as an architectural evolution, not a technical checkbox exercise.
Summary
Migrating to Logic Apps Standard is rarely a simple lift-and-shift. The runtime, deployment model, and operational patterns all change, and those differences need to be understood before production workloads move across. For many organisations, however, those changes unlock a far more scalable, maintainable, and DevOps-aligned integration platform.
The Clone to Standard tool can accelerate the early stages of migration by converting workflow definitions into a Standard project structure. However, it should be viewed as an assistive tool rather than a complete migration strategy. Connector behaviour, configuration management, networking, and runtime characteristics still require deliberate validation.
For organisations with mature DevOps practices, rebuilding workflows within a structured Standard project and deploying through established CI/CD pipelines will often produce the most maintainable long-term outcome. In environments where that structure doesn’t yet exist, the clone capability can provide a useful starting point to bring existing integrations into the Standard model.
If you’re already planning a migration to Standard or are still evaluating whether it’s the right step for your integration platform, the team at Adaptiv can help. We work with organisations across New Zealand and Australia to design and implement integration solutions on Azure Logic Apps and the wider Microsoft Azure platform. If you’d like help assessing your current environment, planning a migration strategy, or executing the move to Standard, feel free to reach out.
