Export workflows from Azure Logic Apps: exit guide

What you can take out of Azure Logic Apps and what you must rebuild

A renewal, a change in consumption charges or a residency requirement is usually the trigger for moving off Logic Apps, and the first question is what leaves with you. The workflow definition and the ARM templates that deploy it can be exported and used as the starting inventory, but connections, managed connector authorizations and anything bound to the Azure runtime must be recreated on the target platform. Plan the migration around that split from the first day. The exportable side is mostly text you can read and version. The workflow JSON holds triggers, actions, expressions and parameters. ARM or Bicep templates describe the Logic App resource, its parameters and sometimes API connection resources. Integration account artifacts such as XML schemas, maps and partner or agreement definitions are also retrievable, though you should confirm the export path for each artifact type in your own tenant. Parameter files and Key Vault references need a separate check, because secret values usually do not travel with the template. The rebuild side covers what the JSON only refers to. Each managed connector call needs an equivalent connection on the new platform, with credentials issued again under your own service identities. Retry policies, concurrency settings, run triggers and error handling should be recorded per action, since their behavior is not always carried over one to one. Run the export against a sample of production workflows, list every connection name and every external endpoint, and turn that list into a migration inventory with one row per workflow and an owner for each rebuild item.

Which Logic Apps artifacts export, in which format

This table lists each Logic Apps artifact you may need to move, the documented export method, the format you receive and the limits to check before you rely on it. Use it to build the migration inventory, and confirm exact menu paths and CLI options in the current Azure portal and Azure CLI documentation before you start.

Artifact	Export method	Format and limits
Workflow definition	Code view in the designer or the workflow definition in the portal, or the Logic Apps REST API and Azure CLI for retrieval	JSON workflow definition in the Workflow Definition Language. Triggers, actions and parameters come across, but connection values reference Azure resources that must be replaced.
ARM templates for deployment	Export template from the resource group or logic app blade in the Azure portal, or export through Azure CLI	JSON Azure Resource Manager template. Confirm whether connection resources and secrets are parameterized or omitted in the export you receive.
Bicep files	Written by your team or converted from an existing ARM template with the Bicep tooling	Bicep source. Bicep is not produced by every export path, so treat it as a conversion step to verify rather than a guaranteed output.
API connection resources	Visible in the resource group as separate resources, reviewed through the template export	JSON definitions that reference Azure-managed connectors. Authentication secrets are not exported as usable values, so credentials must be recreated.
Integration account schemas	Download from the integration account in the Azure portal or retrieve through the integration account REST API	XSD or JSON schema files. Confirm file types and whether all versions are retrievable in the current documentation.
Integration account maps	Download from the integration account in the Azure portal or retrieve through the REST API	XSLT or Liquid map files. Maps depend on the Logic Apps transform engine, so expect manual retesting outside Azure.
Run history and monitoring data	Available only in the Azure portal or Log Analytics, if diagnostics were enabled	Not a deployable artifact. Export run data separately if you need it for reconciliation during cutover.

What does not export and how to recover it

A Logic Apps export gives you the workflow logic, but much of what makes a workflow run in Azure stays behind. Each item below needs a deliberate workaround in the target platform, and each one should be inventoried before you decommission anything in Azure.

Connection objects and stored credentials

Connections and the credentials behind them are not part of the workflow definition. Each API connection, such as a mailbox, database or SaaS login, must be recreated in the target, and the export will only show which connection names a workflow references. Record every connection by name, owner and account, then recreate it in the target and test each action before cutover. Assume every credential will be re-entered, not copied.

API connection secrets in your vault

Secrets used by API connections and parameters often live in Azure Key Vault or were typed into the designer. Those values do not travel with the JSON, so they must be retrieved from your vault or the owning system and stored in the target's credential store. Confirm who holds each secret, rotate anything that was shared widely during the migration, and avoid pasting plaintext values into workflow JSON files that will sit in Git.

Managed identity assignments

System-assigned and user-assigned managed identities are Azure identity objects. They do not move, and the permissions granted to them on storage accounts, Key Vault or APIs stop applying the moment a workflow leaves Azure. Build an inventory of each identity and its role assignments, then decide whether the target will use a service account, OAuth client or certificate. Keep the mapping in your change record.

Azure-hosted runtime and networking

Logic Apps Standard runs on App Service plans, and Consumption workflows run on Azure-managed infrastructure. Virtual network integration, private endpoints, IP restrictions and the trigger endpoints Azure generates are tied to that runtime and do not export. Document each workflow's trigger URL, callers and network path, then plan new endpoints and DNS entries in the target so that inbound callers can be repointed on a known date.

Run history and monitoring data

Run history, action inputs and outputs, and Azure Monitor diagnostic logs stay in Azure and are subject to Azure's retention settings. Before you decommission a resource group, export the run data you need for audit, dispute resolution or troubleshooting to storage you control. Confirm the retention periods your compliance owner requires, since the target platform will not hold Azure's historical records.

Alerts, dashboards and scheduled tasks

Azure Monitor alert rules, action groups, dashboards and recurrence triggers configured outside the workflow definition are separate resources and will not appear in the export. List them from the resource group, then rebuild each alert in the target's monitoring stack and confirm that someone receives the same notifications. Recurrence schedules and time zone settings need the same explicit check.

Export sequence and how to verify each step

This sequence turns a loose estate of Logic Apps into a frozen, versioned inventory of definitions, templates, integration account artifacts and dependencies. Each step ends with a check so you know the export is complete before any workflow is rebuilt.

Freeze the list of workflows in scope
Export the list of Logic Apps in each subscription and resource group you plan to migrate, including Consumption and Standard workflows, and mark which ones are active, disabled or unused. Record the resource name, resource group, region, trigger type and owner for each one in a spreadsheet or work tracker. This list becomes the baseline for every later step. You know it is done when the count of workflows in the portal or Azure CLI output matches the count in your inventory, and every disabled or orphaned workflow has a recorded decision to migrate or retire.
Export workflow definitions and deployment templates
For each workflow, save the JSON workflow definition from the designer's code view or the resource's definition, and export the resource group as an ARM template so that trigger settings, parameters and app settings are captured. Keep the definition files named after the resource and store parameter values separately from secrets. Verification: open the exported JSON side by side with the portal designer and confirm that every trigger, action, branch and loop appears in both, and that the number of actions in the file matches the count shown in the designer. Note any action types you do not recognize for later mapping.
Export integration account artifacts
If workflows use an integration account, export its schemas, maps, partners, agreements and certificate references, which are stored as separate resources and are not part of a workflow definition. Use the portal or Azure tooling to list each artifact type and save each one as a file. Verification: compare the artifact counts per type against the integration account's resource list, and confirm that every map and schema referenced by a workflow action appears in your export. Artifacts referenced by name but missing from the export are a gap to resolve before migration.
Record connector and identity dependencies
Go through each workflow definition and list every connector, managed API connection, custom connector, HTTP endpoint and Azure resource it calls, along with the identity used, such as a managed identity, service principal or stored credential. Mark which dependencies are Azure-managed and which would need a replacement or a new credential on a self-hosted platform. Verification: check that every connection referenced in the definitions has a matching entry in your dependency list, and that each entry names an owner who can confirm the target system still exists and is reachable.
Capture run history and trigger details
For each workflow, record the trigger schedule or endpoint, recent run status, retry settings and any concurrency or pagination limits set in the definition. Also note where run history is needed for reconciliation during cutover, and which runs must not be replayed. Verification: confirm that the trigger details in your notes match the definition file and that the recent run statuses agree with the portal's run history for a sample of workflows you select. Discrepancies usually point to settings changed outside the definition.
Store the export in version control
Commit the workflow definitions, ARM templates, integration account artifact files, dependency list and trigger notes to a Git repository with a clear folder structure per resource group, and exclude secrets, keys and connection strings. Tag the commit as the baseline for migration. Verification: clone the repository into a clean folder and check that the file count and workflow names match the frozen inventory from the first step, and that a secret scan reports no credentials. Ask your security team to confirm the scanning rules before the repository is shared.

How to turn the export into a migration inventory

Start the inventory with one row per workflow, built from the exported definition JSON and the ARM templates you pulled for each Logic App. Record the trigger type first, because it decides how the workflow starts in the target: a recurrence schedule, an HTTP request trigger, a Service Bus or queue message, or a file or database poll each need a different replacement. Next, list every action in run order, including Condition, For_each, Until and Scope blocks, since nested control flow is where rebuild effort tends to hide. Add columns for the connectors used (Office 365, SQL, Service Bus, Blob storage, HTTP and so on), noting whether each one is a managed connector or a custom connector, and for the API connection resource each one depends on. Finally, capture the environment (dev, test, production), the resource group and region, the owner, and the business process the workflow supports.

Add two columns that are easy to skip and expensive to miss: schemas and maps. Find every Liquid map, XML transform and schema reference in the integration account and tie each one to the workflow that calls it. For the target platform, map the rows to concepts you already know. In n8n, the trigger becomes a trigger node, each connector becomes a node or an HTTP Request node, and expressions and Set or Code nodes carry the data mapping. In Apache Camel, the trigger becomes a from endpoint, each action becomes a processor or a component call in a route, and transforms become transform or data format steps. Mark rows where no native equivalent exists, such as a managed connector with no community node, so they are scoped separately. Confirm each connector's coverage against the current n8n node list or Camel component catalog instead of assuming parity, because coverage changes by release. Use the inventory as the working plan for the workflow-by-workflow cutover, not as a one-time report. Sort rows by risk, placing workflows that touch shared connections or that run on tight schedules in later waves, and add a status column for rebuilt, tested, parallel-running and retired. Record the secrets and connection credentials each workflow needs, because Logic Apps connection objects do not carry the secret values in the export and you will recreate them in the target. Keep the inventory in version control or a controlled document store, and review it with the owners of each row before any production cutover.

What to plan before the Azure contract or subscription ends

The export itself is the easy part. The decisions that cause trouble are who can export, how long the Azure resources stay alive, and what billing terms apply when workflows keep running in parallel. Work through these before a renewal date or termination notice forces the timeline.

Confirm export access and roles

Check which Azure roles can read Logic App definitions, run-history and connection metadata in each resource group, and which accounts can view ARM templates and integration account artifacts. Ask the Azure administrator who owns each workflow, because the people who built a workflow are often not the people with subscription-level rights. Test an export with a read-only account before the migration window opens, so you do not discover missing permissions during cutover.

Schedule exports early

Export every workflow definition and ARM template while the subscription is fully active and the workflows still run. Store the files in version control with a dated folder so later changes are traceable. Repeat the export shortly before cutover, because workflows edited during the project will otherwise drift from the inventory you built.

Check resource and retention needs

Identify storage accounts, Service Bus namespaces, Event Grid topics and log destinations that hold message history, audit data or evidence you must keep. Confirm with your compliance team how long run history and diagnostic logs must be retained, and whether Azure's own retention settings meet that requirement after the subscription is closed. Export the data you need to keep before any resource is deleted, since deleted resources usually cannot be recovered.

Keep parallel running during cutover

Run the new n8n or Camel workflow alongside the Logic App for each integration until output matches on real traffic. Disable the old trigger only after the new one has processed the same events. Plan for duplicate processing during this window and confirm that downstream systems can tolerate it, especially for payments, order updates or notifications.

Confirm billing and commitment terms

Ask Microsoft or your reseller which commitments, reservations, enterprise agreement terms or hybrid vCPU charges apply to your Logic Apps usage, and how notice periods and early termination work. Confirm whether any spend commitment continues after workflows are switched off. These terms depend on your agreement, so verify them directly with Microsoft rather than relying on list prices.

What the export work asks of each team

The integration owner runs the inventory. This person or small group decides which Logic Apps workflows exist, which are live, which are dormant, and which business process each one supports. The export is only as useful as the list it sits in, so this role carries the largest share of the discovery effort.

Workflow list: Record every Logic App in scope, its resource group, its trigger type, its owner and its last run date.
Definition export: Keep the JSON workflow definition for each workflow, taken from the portal or the Azure CLI, under version control.
Connector map: List every managed connector and API connection each workflow calls, and note which ones depend on a named account.
Dependency notes: Record which downstream systems, schedules and other workflows each one feeds, since these determine cutover order.
Ownership sign-off: Get a named business owner to confirm which workflows must move and which can be retired.

Before the inventory is closed, confirm with the business owners that every workflow in the list has been reviewed, including those that run only at month end or on error paths.

Questions teams ask before exporting Logic Apps workflows

Can I export Logic Apps workflows from the Azure portal or the CLI?

Confirm the current export options with Microsoft's Logic Apps documentation before you plan, because the material behind this page does not describe the export mechanics. In general terms, the portal suits a handful of workflows, while scripted tooling suits a large estate. Ask Microsoft which export paths return the workflow definition, which return ARM templates, and which artifacts each path leaves out. Whichever path you choose, store the output in version control so every workflow has a dated, reviewable copy. Record the export path used for each workflow in your inventory, because the output format decides how much parsing the migration needs.

Do Logic Apps exports include connections and their credentials?

Plan on recreating connections after export, and confirm the exact behavior with Microsoft. A workflow definition refers to a connection by name, while credentials, consent and managed connector setup sit in Azure. Make's help center states that its blueprint export leaves connections out and that they must be recreated after import, which is a useful pattern to expect. Record every connection name, connector type and the system that owns each credential. Store secrets in your own vault instead of copying them from the export, and rotate them as part of cutover.

How long does exporting a large Logic Apps estate take?

No researched figure is available for export time, so ask Microsoft and measure it on your own estate. Duration depends on the number of workflows, the mix of Standard and Consumption workflows, how many resource groups and subscriptions are in scope, and whether the export is scripted or done by hand. Run a pilot on a representative set of workflows to measure your own throughput, then scale the result using the count in your inventory. The longer part is usually the review of each export for connections, parameters and environment-specific values, which grows with the number of workflows and matters more than the export command itself.

What do we need from internal staff for the export?

Assign named roles before anyone runs an export, because the technical step is the smallest part of the work. Typically the effort involves:

An Azure administrator with read access to the Logic Apps, resource groups and integration accounts in scope, with the exact role names confirmed in Microsoft's documentation.
A workflow owner from each business area who can confirm what each workflow does, whether it still runs, and which systems it touches.
A security or identity contact who can identify the credentials, managed identities and network paths each workflow depends on.

Budget time for these people to review the inventory, since they hold the knowledge the export file does not contain.

Can our own team run the Logic Apps export without outside help?

A team with the right Azure access can usually run the export itself, but confirm the tooling and permissions with Microsoft first. Doing it in-house works best when the estate is small, documentation is current and one person understands the Azure environment. Outside help is worth considering when workflows depend on integration account artifacts, hybrid runtimes or many undocumented owners. DeployOpen plans, implements and documents self-hosted open-source platforms in your own infrastructure, and it can take on inventory and export work under a fixed scope agreed in writing before work starts. Ongoing support is available as a retainer.

What drives the cost of an export and inventory up or down?

Most of the cost is people time for review, not the export itself. Costs rise with the number of workflows, the number of connections that must be recreated, undocumented business logic, integration account artifacts such as schemas and maps, and the number of owners to interview. Costs fall when workflows follow consistent naming, owners are available, and the estate is already documented. Any Logic Apps charges you already pay continue until cutover, so a slow inventory has its own cost. Ask any provider for a quote that itemizes inventory, export scripting, connection review, owner interviews and a written list of exclusions.

Are ARM templates enough to rebuild our workflows elsewhere?

ARM templates on their own are unlikely to be enough, because they describe Azure resources and their configuration, which is a different thing from a workflow's logic. Treat them as one input to the inventory, and confirm with Microsoft what each template contains and omits for Logic Apps resources. Pair them with the workflow definition, connection list, integration account artifacts and owner notes. Mark any workflow where the logic is unclear, because those need a rebuild decision and a test plan before cutover. Keep each source file in version control so the inventory can be traced back to the exact export it came from.

How to verify the export is complete before you cancel anything

Treat the export as incomplete until it passes four acceptance checks. The first is a round-trip diff: re-export every workflow definition after the first export, then compare the two sets of files. A clean diff shows the export captured the current state and nothing changed in between. Any difference in a definition, parameter or connection reference means the inventory is stale or someone edited a workflow during the export window. Run the comparison on the JSON definitions and the ARM templates separately, because a template can hold parameters that the definition file does not show. Confirm with Microsoft's current Logic Apps documentation which export commands and validation tools it supports for your plan type (Consumption or Standard), since the export paths differ.

The second check is inventory coverage. Every row in your migration inventory should point to at least one artifact on disk: a definition file, a template, a parameter file, a schema or a map from the integration account. Rows without an artifact are the gaps that surface after cutover. Count the rows against the artifacts and resolve each mismatch by either exporting the missing item or recording it as a manual rebuild with an owner. Connection objects belong in the same review. Their secrets will not export, so each connection row should show who will recreate it and where the credential will be stored.

The third check is a reimport test in a non-production environment. Deploy the exported templates to an isolated resource group or subscription, then confirm the workflows deploy, the triggers register and the expected actions appear in the designer. Expect failures on connections and on any reference to resources that do not exist in the test environment. Record each failure and classify it as a parameter problem, a missing connection or a missing artifact. Do not disable the source workflows during this test. The final check is sign-off: the migration owner, a security reviewer and the team that operates each integration should each record their acceptance against the inventory, with the export date, the source subscription and the diff results attached. Only after that record exists should anyone disable or delete a Logic Apps resource.

How DeployOpen scopes and delivers a Logic Apps exit

DeployOpen is a Chainscore Labs company that plans, implements, integrates, documents and supports self-hosted open-source platforms inside your own infrastructure. For a Logic Apps export, we treat the exported definitions, ARM templates and integration account artifacts as the starting inventory, then agree in writing what gets rebuilt, tested and handed over.

How we scope

Inventory every Logic App, its trigger type, connectors and whether it runs Consumption or Standard.
Record which connections, integration account schemas and maps each workflow depends on.
Agree in writing which workflows move, which stay, and what the cutover order will be.

How we build

Rebuild workflow definitions on the chosen target, mapping each connector to a self-hosted equivalent.
Recreate credentials and connections in the target's secret store, not from exported files.
Test each workflow against its original inputs, outputs and failure paths before switching traffic.

How we hand over

Deliver a migration inventory that maps every source workflow to its target, status and owner.
Document the deployment, configuration, backup and rollback steps for your operations team.
Provide runbooks that describe how to version exported definitions and redeploy them.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retainers can cover target platform upgrades, security patching and changes to rebuilt workflows.
Confirm support terms, response expectations and included services in the written scope before work starts.

How to export your workflows from Azure Logic Apps