What you can export from Power Automate and what stays behind
Power Automate lets you export flows in two forms: a single-flow package that only the flow owner can export, and a Dataverse solution that bundles a group of flows with their related components. Neither format is a portable workflow definition that n8n or Activepieces can import, so the real work is building an inventory of every flow and rebuilding each one on the new platform. If your renewal or license change is still ahead, start that inventory now, because the people who own flows may leave or change roles before the rebuild begins.
Start by listing every flow across all owners and environments, noting its triggers, actions, connectors, connection owners, and whether it depends on an on-premises data gateway or a desktop flow. Use the export options as a reference copy of each definition, not as the thing you import. Confirm the current export behavior, package contents, and any size or count limits in Microsoft's Power Automate documentation and by testing an export in your own tenant, since these details change and should not be assumed from older guidance. Ask your Microsoft account team or licensing contact which of your flows and connections will stop working when your licenses lapse.
Plan the rebuild around what the export cannot carry: connection credentials, environment-specific references, and owner-level permissions have to be recreated by hand on the target platform. Record which flows are business-critical, which depend on Microsoft 365 connectors, and which need approvals or sharing rules, so you can sequence the rebuilds and run old and new flows in parallel before switching off the originals. This inventory also becomes the evidence base for any cost comparison and for deciding which flows should stay inside Microsoft 365.
Which Power Automate data types you can export and how
This table lists each kind of Power Automate data you may need to take out, the export method that covers it, the file format, who can run it and what to confirm before you rely on it. Read it as an inventory checklist: a single-flow package does not carry everything a solution does, and run history is not a rebuild artifact. Treat every export as reference material for rebuilding in another tool, since none of these formats imports directly into n8n or Activepieces.
| Data type | Export method | Format | Who can run it and what to confirm |
|---|---|---|---|
| Single cloud flow | Export package from the flow's details or editor | .zip package | Flow owners only. Confirm the owner restriction and any size or count limits in Microsoft's current Power Automate documentation. |
| Dataverse solution containing flows | Export solution from the Power Platform maker portal | Dataverse solution file | Users with rights to the solution's environment. Confirm environment scope and which components a solution includes. |
| Flow run history and activity | Review in the flow's run history view or admin reporting | Portal view, not a rebuild artifact | Owners and admins with reporting access. Confirm retention periods and whether runs can be exported at all in your tenant. |
| Flow definitions in admin center or portal | Browse or list flows in the Power Platform admin center or Power Automate portal | Screen view or admin export | Tenant and environment admins. Confirm which listing and export options your license and admin roles expose. |
| Connection references | Inspect in the solution or the flow's connections | Metadata inside the solution file | Makers and admins. Plan to re-create each connection in the target tool, since credentials do not carry over. |
What does not export cleanly and how to work around each gap
A Power Automate export carries flow logic but leaves behind the things that depend on your tenant, your people and your machines. Each card below names one gap, the reason it matters for your rebuild, and the step that keeps the migration moving.
Connection credentials and secrets
Connections bind a flow to a user's or service account's sign-in to Microsoft 365, SharePoint, Salesforce or other services. Exported packages do not carry these credentials, and they are not meant to travel with a package. Treat every connection as a new credential in the target tool, owned by a named service account where possible, and record which account each flow used before you export. Check that the target platform stores credentials encrypted and that you can rotate them without editing flows.
On-premises data gateway configuration
Flows that reach on-premises databases or file shares depend on a gateway installation, its cluster and the data source mappings inside it. None of that appears in a flow package, so the flow alone cannot tell you where data was read from. Before you decommission a gateway, export a list of its data sources and the flows that use each one from the admin center. Confirm which network paths and firewall rules your self-hosted replacement needs, since the gateway is not part of the export.
Environment variables and stored values
Environment variables hold settings such as URLs, folder IDs and feature switches, and their current values can differ between development, test and production. A solution can list variable names, but the stored values and any secrets referenced through them must be captured separately. Record each variable's name, purpose and value per environment in your inventory, and mark which values are secrets so they move through your secrets manager instead of a spreadsheet.
Flow run history and audit records
Run history shows when each flow executed, what it processed and where it failed, and it is the evidence many audits ask for. Exports cover flow definitions, not the run log, and the log's retention is set by your Power Platform configuration rather than by the flow itself. Decide which records your auditors need before the license ends, then archive run summaries and relevant audit data into your own log store. Confirm the retention period in your tenant settings rather than assuming it.
AI Builder models and custom connectors
Flows that call AI Builder models or custom connectors depend on objects that live in the Power Platform environment, not in the flow file. A flow may reference a model or connector that will not exist once you leave the platform. List every such dependency during inventory, export the connector definitions and API specifications where you own them, and decide whether each model's logic should be rebuilt with a standard API, a local model or a third-party service that your data rules allow.
Desktop flows on machines outside the cloud
Desktop flows run on named machines that hold their own files, credentials and local app installations, and they are not stored as cloud flows. Their logic can be exported as a package, but the machine, its scheduling and the bot hosting it do not move with it. Inventory each desktop flow, the machine and account that runs it, and the legacy application it drives. Plan the replacement separately, because an API integration and a screen automation tool need different controls and different hardware.
Why a Power Automate package does not import into another tool
A Power Automate package is a specification for rebuilding your flows, not a migration file. It describes triggers, actions, connector references, expressions and approval steps in Microsoft's own schema, and those references point to Microsoft-hosted connectors and, for solutions, to Dataverse tables and environment variables. No other automation tool reads that schema as a runnable workflow, so an import into n8n, Activepieces or any other platform will not produce a working flow. Treat each exported file as documentation of what the flow did, including its trigger conditions, branching and error handling, and plan to recreate it.
The practical work starts with the connectors. Every connector named in the package, such as a Microsoft 365, SharePoint, SQL Server or SaaS connector, must be mapped to a native node or integration in the target tool, or to an HTTP or API call that performs the same operation with credentials you manage. Each mapping needs a check of the authentication method, the scopes or permissions granted, and any on-premises data gateway dependency, since those credentials and network paths do not carry over. Confirm with the target platform's documentation which integrations exist before you assume a mapping, because coverage differs between tools and between editions.
Approval steps and expression logic are the parts that need the most manual attention. Power Automate approvals, conditions, loops and expressions are written in its own expression language, and the package keeps them as definitions that must be re-expressed by hand in the target tool's syntax and data model. Check who approves, how timeouts and rejections are routed, and which fields are passed between steps. Record each rebuilt step against the original definition in your inventory, and have the flow owner sign off on behavior before switching the old flow off.
Who can export flows: owners, admins and makers
Flow owners can open each cloud flow they own and export it as a single package file from the flow's details. Single-flow export is scoped to ownership, so the export covers only the flows the signed-in user owns. Co-owners generally have the same reach for the flows they share, but confirm how co-ownership works for export in Microsoft's documentation for your tenant before you plan around it.
- Exports they can make: Each flow they own, one package at a time. The package holds the flow definition, including triggers, actions and parameters.
- What they cannot see: Connection credentials, which you should expect to recreate on the target tool, and flows owned by colleagues who only ran or viewed them.
- Departed makers: Flows owned by someone who has left cannot be exported by anyone else until ownership is reassigned. Offboarding is the point where these flows are most at risk.
- Request in advance: Ask the tenant admin for a list of flows whose owner is inactive, and ask how ownership is reassigned during offboarding.
Before any license change, check which flows in your tenant have no active owner, because those flows need an admin plan rather than an owner export.
Environment admins manage the Power Platform environments that hold flows, connections and related components. Dataverse solutions group flows with the components they depend on, and a solution export works only from the environment where that solution was built. If a flow was never added to a solution, a solution export will not include it, no matter how important the flow is to the business.
- Solution export: Groups of flows packaged together with their dependencies, exported from the environment that holds the solution.
- Wrong environment: Flows built in a personal or default environment are often missing from any solution, so the export misses them unless someone moves them first.
- What they cannot see: Flows in environments they do not administer, and flows owned by makers in other environments unless the admin has been granted access.
- Request in advance: An environment inventory, the list of solutions in each environment, and a report of flows that belong to no solution.
Confirm in Microsoft's documentation which admin roles can export solutions, and whether managed and unmanaged solutions behave differently in your tenant, because that affects how the package can be reused.
Business makers build flows in their own workspace, often without any admin role. They can export the flows they own, one at a time, but they usually have no view of the tenant, the environments or the admin settings that the flows depend on. Their knowledge of what a flow does is often the most valuable input to a migration, and it is rarely written down.
- Exports they can make: Their own flows as package files, one flow per export.
- What they cannot see: Other people's flows, the tenant-wide inventory, and the connector, gateway and approval settings that the admin controls.
- Hidden dependencies: Flows often rely on connectors, on-premises data gateway connections or approval steps that a single package does not fully describe, so the maker needs to document them.
- Request in advance: Ask each maker to record every flow's trigger, business owner, systems it reads or writes, and the people who approve its outputs, in a shared sheet the admin can read.
Ask makers to walk through their flows with this checklist before any license decision, and confirm with the admin which of their flows need a solution export instead of a personal one.
The export sequence and how to verify each step
This sequence turns scattered cloud flows into a verified inventory and a set of exported packages that you can check against the source. The result is a record you can use to plan rebuilds before licenses or environments change.
Build a flow inventory across all environments
Start by listing every flow in every Power Platform environment, including development, test and production, and any flows owned by people who have left the organization. For each flow, record the owner, the trigger, every connector it uses, how often it runs and the business owner who relies on its output. Check the inventory by counting flows per environment in the admin center and confirming the total matches your list. Any flow that appears in one environment but not the other is a gap to resolve before going further.
Assign a keep, rebuild or retire decision
Walk through the inventory with each business owner and mark every flow as keep, rebuild or retire. Flows that have not run in a long time or duplicate another flow are candidates for retirement, but confirm that with the business owner before deciding. Record the decision and the name of the person who approved it in the same inventory row. The check is that no flow remains without a decision, and that every retire decision has a named approver.
Export packages for owned flows and solutions for groups
Export single flows as .zip packages for the flows you own, since Power Automate allows only the owner to export an individual flow. For flows that belong together, export them as a Dataverse solution so their dependencies travel as a group. Keep the exports as a reference for rebuilding, not as something you expect to import into another tool. The check is that each keep or rebuild flow has either a package or a solution entry in the inventory, and that flows you do not own are listed for transfer to an owner who can export them.
Store exports with a checksum and a read-me
Place each package and solution file in controlled storage with access limited to the migration team. Generate a checksum for every file and record it in the inventory, then add a short read-me to the folder that names the source environment, the export date and the person who ran the export. Verify storage integrity by recalculating one or more checksums after the copy and confirming they match. A mismatch means the file must be re-exported from the source before the rebuild starts.
Reopen each package and match its actions
Open each package in a separate, non-production review step and list the triggers and actions it contains. Compare that list with the inventory row for the flow, checking that the trigger type, the connector list and the number of actions match what you recorded. Where the counts differ, investigate whether the flow changed after the inventory was taken or whether the inventory missed a step. The check is a signed-off comparison for each flow, with every discrepancy either resolved or noted for the rebuild team.
Record connections, gateways and credentials needed
For each flow, record every connection it uses, the account that owns that connection and any on-premises data gateway it depends on. Note which secrets, service accounts and API keys must be recreated in the target tool, because connection credentials do not carry over in an export. Confirm that every connector named in the packages appears in this record, and that every gateway has a named owner in your infrastructure team. The step is complete when the connection register covers all keep and rebuild flows and each entry has someone accountable for recreating it.
How much effort does a Power Automate flow export take?
How much effort does exporting and inventorying Power Automate flows take?
The effort depends mostly on how many flows exist, how many environments they live in, and how many connectors and owners are involved. A small set of flows owned by one person in one environment is a short exercise. A large estate spread across several Power Platform environments, with flows that depend on on-premises data gateways and custom connectors, takes much longer because each flow must be found, read and recorded. Ask your team for a count of flows per environment and per owner before you estimate anything.
Can our own team export and inventory the flows without outside help?
Yes, many teams can do the inventory internally, especially if they already administer the Power Platform. The work is mostly reading and recording: which flows exist, who owns them, which triggers and connectors they use, and whether they run on a schedule or on an event. The harder parts are judging which flows still matter and deciding the rebuild order. Be honest about staff time, because the people who know the business logic are often the same people who are needed for daily work.
What access and sign-offs does a flow export need from us?
Plan for three inputs: administrator access to the Power Platform environments that hold the flows, sign-off from flow owners on which flows are still in use, and a complete list of connectors and their accounts. Owner-only export is a real limit in Power Automate, so an administrator may need to ask owners to export their own packages or confirm that solution-level exports cover what is needed. Confirm with your Microsoft 365 and Power Platform administrators which roles your organization uses to grant this access.
How long does the export and rebuild planning take, and what sets the timeline?
No duration figure is published in the sources for this page, so treat any number you hear as a question to confirm. The main drivers are the number of flows, how many owners must respond, how many flows depend on gateways or custom connectors, and whether your license renewal date gives you a fixed deadline. Build the schedule around the license end date and leave room for owners who are slow to answer. A written scope should state the flow count, environments and milestones before work begins.
Can exported Power Automate packages be imported into n8n or Activepieces?
No. Power Automate exports are packages that describe flows in Microsoft's format, and neither n8n nor Activepieces imports them. Treat the exports as a reference for each flow's triggers, actions, conditions and connector names, then rebuild the logic in the target tool. Connections also have to be created again on the new platform with credentials you control. Confirm this for your specific version of each tool before you plan around it.
What happens to flows owned by people who have left the organization?
Flows owned by former employees are a common risk because nobody can confirm their purpose or current use. Start by checking whether a flow is still running and which connections it uses, since those connections may be tied to a departed user's account. Assign an active owner, decide whether to rebuild, retire or archive each flow, and record that decision. Ask your administrators whether ownership can be transferred in your tenant and whether the flow's history remains available after the owner account is removed.
What should we ask for in a quote for this work?
Ask for a written scope that lists the environments, flow count, connectors, gateways and owners covered, plus the deliverables: a flow inventory, a rebuild priority list and the export references. Ask which items are one-time work and which recur, such as ongoing support or upgrades. Ask how the provider handles flows whose owners have left, what access they need, and what happens if the flow count changes after the scope is agreed. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and provides a quote from that written scope.
What to plan before the Power Automate contract ends
Power Automate exports are tied to licenses, owners and environments, so the work starts before access is removed. The six items below sequence the decisions, and each one produces an artifact that the next step depends on.
Confirm export entitlement and lapse date
Find out which license or plan lets your team export flows, who holds it, and the exact date access ends. Export rights for single-flow packages are limited to flow owners, so a departing maker can take flows out of reach. Record the entitlement terms in writing from Microsoft or your licensing partner, and confirm retention terms for tenant data after the contract ends.
Freeze flow changes for a set window
Agree a defined change freeze on the flows in scope so the export reflects a known state. Decision owner: the head of the automation program, with sign-off from business owners of each flow. Artifact: a freeze notice listing flow names, environments and the start and end dates, plus a rule for emergency fixes that must be re-exported.
Export and archive before access is removed
Export each flow as a package and every solution as a Dataverse solution while owners can still sign in. Store the files in your own controlled repository with checksums and a manifest. Artifact: an archive index mapping each package to its flow, owner, environment and export date, which becomes the reference for rebuilds.
Plan a parallel run of rebuilt flows
Rebuilt flows in n8n or Activepieces should run beside the originals for a fixed period so outputs can be compared. Decision owner: the process owner for each flow. Artifact: a parallel-run test plan with inputs, expected outputs, connector checks and a sign-off record before the Power Automate version is switched off.
Decide the fate of desktop flows and bots
Desktop flows depend on Windows machines, local credentials and bot licenses that a cloud-flow export does not capture. Decide per flow whether to retire it, replace it with an API integration, or move it to another RPA tool. Decision owner: the infrastructure lead for machines and the business owner for each process. Artifact: a desktop flow register listing machine, credential store and disposition.
Set retention for packages and run history
Exported packages contain business logic, connection names and sometimes sensitive values, so they need the same controls as other records. Decision owner: the data protection officer with records management. Artifact: a retention schedule covering package storage location, access list, encryption, deletion date and whether run history is kept. Confirm any legal hold requirements with counsel before deleting anything.
How DeployOpen scopes an exit from Power Automate
DeployOpen plans and runs the export and rebuild work for Power Automate flows inside your own infrastructure, as a fixed-scope engagement agreed in writing before work starts. The result is an inventory, a set of rebuild plans and handover documentation that your own team can keep using.
How we scope
- Inventory every cloud flow by owner, environment and connector before choosing what to export or rebuild.
- Record which flows depend on Dataverse solutions, on-premises gateways or Microsoft 365 connectors that need confirmation.
- Agree in writing which flows are in scope, which stay on Microsoft 365, and the license dates that set the timeline.
How we build
- Export flow packages and solutions as reference copies, then recreate triggers, actions and connections in the target tool.
- Rebuild in a self-hosted n8n or Activepieces instance inside your network, with secrets kept in your own store.
- Test each rebuilt flow against the original outputs and run both versions in parallel until the owners sign off.
How we hand over
- Deliver the flow inventory, mapping sheets, rebuild notes and test records as documents your team owns.
- Document each connection that had to be recreated by hand, including the credentials and owners needed to restore it.
- Walk your makers and operators through the new builder and the runbook before the Power Automate licenses are retired.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Ask for the support scope, response expectations and upgrade process in the written proposal, since these vary by engagement.
- Confirm with DeployOpen which post-migration tasks, such as backups and version upgrades, are included in your scope.
