Migrate from Power Automate to n8n

Migrate from Power Automate to n8n: what the work involves

If your renewal, a licensing change or a residency requirement is pushing you toward n8n, plan for rebuilding flows rather than importing them. Power Automate exports do not import into n8n, so every cloud flow becomes a new n8n workflow that someone designs, tests and connects. The effort depends on three things: how many flows are in scope, how many distinct connectors they use, and how many depend on the on-premises data gateway. A small set of flows against common SaaS apps is a very different project from hundreds of flows built on Dataverse and on-premises SQL. The work usually splits across three groups. The platform team installs and hardens n8n in your infrastructure, sets up PostgreSQL, backups and the encryption key handling, and replaces gateway connections with network paths the n8n host can reach. Flow owners, the people who built the flows, confirm business logic, approval paths and error handling, since exports show structure but not intent. Security reviews credential storage, service accounts and who may edit workflows. DeployOpen can act as the implementation partner for the platform build and the rebuild plan under a written scope, but your owners still decide what each flow must do. Ask any partner to show how they will track each rebuilt flow against its original. The main risks are silent: a rebuilt flow that runs but misses an edge case, a connection that works under a personal account that later leaves, or a gateway path that was never documented. Plan a parallel run where both systems process real or mirrored events, compare outputs, and switch off Power Automate flows one owner at a time. Confirm with your Microsoft account team what export options and license terms apply to your tenant before you set the switch-off date, and confirm with n8n which edition covers the features you need, such as SSO or environments, in its pricing page.

Which Power Automate capabilities map to n8n and which need rework

This table compares the main Power Automate cloud flow capabilities with their closest n8n equivalents and marks each as clean, needs rework or gap. Confirm connector availability for your own n8n version and edition before you commit to a flow, because Microsoft 365 and gateway paths differ from n8n's built-in nodes. Most flows map cleanly, but approvals, environment promotion and the on-premises gateway need planning.

Power Automate capability	n8n equivalent	Status and what to confirm
Triggers (scheduled, HTTP request, record change)	Schedule Trigger, Webhook and app trigger nodes	Clean for schedule and webhook triggers. Confirm each app trigger exists in your n8n version, since polling and event behavior can differ.
Actions and standard connectors	Built-in nodes for common apps and HTTP Request for anything else	Needs rework where a connector has no native node. Rebuild the call with HTTP Request and re-create credentials.
Expressions and dynamic content	Expressions in n8n using JavaScript syntax	Needs rework. Power Automate expression functions do not map one to one, so test each formula with sample data.
Microsoft 365 connectors (Outlook, SharePoint, Teams, Excel)	Microsoft nodes or Graph API calls through HTTP Request	Needs rework. Confirm node coverage and the Microsoft Graph permissions your tenant grants to the n8n app registration.
On-premises data gateway connections	n8n running inside your network, reaching internal systems directly	Needs rework. Gateway connections are replaced by network access from the n8n host, so confirm firewall rules and database credentials.
Approvals (Approvals connector, approval actions)	Wait node with a resume URL or a custom approval step built on Microsoft Teams or email	Gap for native approval workflows. Confirm whether your n8n edition and integrations give the approval experience your reviewers need.
Environments (dev, test, production) and solutions	Separate n8n instances or a Git-based environments feature on Business and Enterprise plans	Needs rework. The environments feature with Git is listed only for Business and Enterprise plans, so confirm the plan you need.
Error handling (configure run after, retry on failure)	Error Trigger workflows and node-level retry settings	Needs rework. Map each run-after path to an error workflow and test alerting before switching off the flow.
Scheduling and recurrence	Schedule Trigger with cron expressions	Clean for most recurrence patterns. Confirm time zone handling and daylight saving behavior on your own server.
Desktop flows (RPA)	No n8n equivalent	Gap. n8n does not provide desktop RPA, so desktop flows need a separate tool or an API integration.

What exports, what does not, and which integrations to rebuild

Power Automate gives you less to carry over than the flow count suggests. Exports work as reference documentation, while triggers, connections and gateway paths are rebuilt in n8n. The cards below separate what you can keep from what you must recreate, and what needs a decision before cutover.

Single-flow packages stay owner-only

A single-flow .zip package from Power Automate can be exported only by the flow's owner, so a flow owned by someone who has left the company may not be exportable without help from an administrator. The file describes the flow's steps and settings, but it does not import into n8n. Treat each package as reference documentation: open it, record every trigger, condition, loop and action, and note the connector each one uses. Collect these records into your inventory before any licenses lapse.

Dataverse solutions cover groups, not portability

Dataverse solutions bundle several flows, along with the apps, tables and environment variables they depend on, so they suit whole-environment reviews better than single flows. Neither a solution nor a single-flow package carries a usable n8n workflow, so each flow is still rebuilt by hand. Use the solution's component list to find dependencies that the flows rely on, such as lookup tables or variables that feed a Teams notification. Those dependencies need a home in n8n before cutover.

Connections and credentials are re-created

Connections in Power Automate are tied to the user or service account that authorized them, and no credential moves with the flow. In n8n, create each credential again under a service identity you control, with the minimum scope the workflow needs. Record who owns each credential, when it expires and which workflows use it. A shared mailbox or SharePoint site connected under a personal account is a common source of failures after the original maker leaves.

On-premises gateway paths need an n8n host

Flows that reach on-premises SQL Server or file shares through the on-premises data gateway have no direct equivalent in n8n. Deploy an n8n instance, or a worker in queue mode, on a host inside the network that can reach those systems, and point each rebuilt node at the internal address. Confirm that the host can resolve internal names, that firewall rules allow only the required ports, and that the database account has the same least-privilege scope the gateway used.

Encryption keys in queue mode

In n8n queue mode, the main instance hands executions to workers through Redis, and the workers read credentials from PostgreSQL. Every worker and webhook processor therefore needs the same encryption key as the main instance, or it cannot decrypt stored credentials. Store the key in your secrets manager, set it identically on each node, and test a credential-backed workflow on a worker before cutover. Losing the key makes every stored credential unreadable, so back it up separately from the database.

Integrations to rebuild first

Start with flows that touch Microsoft 365 mail, Teams, SharePoint, and on-premises data, because these carry the most connection and network risk. Rank the rest by business impact and by how many other flows depend on their output. For each flow, decide whether n8n has a native node for the service, whether an HTTP Request node covers the API, or whether the flow should stay in Microsoft 365. Confirm each choice with the flow owner before you rebuild it.

Migration sequence from flow inventory to decommissioning

This sequence moves Power Automate cloud flows to n8n in an order that keeps business processes running at every stage. Each step produces a written artifact, so the team can see what was moved, what was tested, and what was switched off.

Build the flow inventory by owner and environment
Export a register of every cloud flow across your Power Platform environments, recording the owner, environment, trigger, connectors, connection references, run frequency, and whether the flow is owned by a person or a shared group. Ask your Power Platform administrator to confirm which environments exist and which flows sit outside them, since flows owned by users who have left the organization need a named successor before anything else happens. The output is an inventory register that assigns every flow an owner, a business purpose, and a migration decision of rebuild, retire, or keep in Microsoft 365.
Export packages and solutions as reference
Export each flow as a package and export the relevant Dataverse solutions, then store them in version control or a restricted archive. Treat these files as a reference for the logic, actions, and expressions you are rebuilding, not as something n8n will import, because they do not move into another tool. Confirm with your administrator who can perform these exports, since individual flow packages can usually only be exported by their owners. The output is an archived reference set, with each file linked to its row in the inventory register.
Decide the n8n architecture
Choose between a single n8n main instance backed by its own database and queue mode, where the main instance hands executions through Redis to worker processes that read and write workflow data in PostgreSQL. Queue mode requires the encryption key to be shared with every worker and webhook processor so they can read stored credentials, so the key must be managed in your secrets store from the start. Multi-main high availability is limited to Enterprise self-hosted deployments, so confirm with n8n whether your edition supports it before you design around it. The output is a signed architecture note covering hosting, database, Redis, key management, and the license edition in use, checked against n8n's hosting documentation.
Rebuild and test a pilot flow
Select one low-risk flow with a clear owner and a known expected output, then rebuild its triggers, actions, and conditions in n8n. Recreate each credential in n8n rather than copying it, and replace any on-premises data gateway dependency with a network path your n8n workers can reach. Run the pilot against test data and compare its results with the Power Automate run history for the same inputs. The output is a pilot test record showing inputs, expected outputs, actual outputs, and the owner's written acceptance.
Run both platforms in parallel and reconcile outputs
For each rebuilt flow, keep the Power Automate version active while the n8n version runs against the same triggers or in shadow mode, and compare outputs, record counts, error counts, and side effects such as emails sent or records written. Investigate every difference, because differences often come from date handling, empty values, or connector defaults that behave differently between the two tools. Agree with the flow owner how long the parallel run continues before cutover. The output is a reconciliation log per flow, signed by the owner, that lists each discrepancy and its resolution.
Cut over each flow with a signed checklist
Switch one flow at a time by disabling the Power Automate version and enabling the n8n version, with a rollback step documented for that flow. Before cutover, confirm that the n8n credentials are working, that scheduled or webhook triggers point at the new endpoints, and that any downstream system expecting the old notifications has been informed. Record the cutover time and the person who approved it. The output is a signed cutover checklist for each flow, held alongside its reconciliation log.
Decommission Power Automate flows and connections
After a flow has run successfully on n8n for the agreed period, turn off the Power Automate flow, remove its connection references, and delete the on-premises data gateway connections that no longer serve any flow. Keep the exported reference packages and the reconciliation logs for audit and recovery, and update the inventory register to show each flow as retired or kept. Confirm with your licensing contact that removing these flows changes your Power Platform entitlements as expected. The output is a decommissioning record that closes each inventory row and confirms that no active flow or connection remains without an owner.

How the n8n runtime and credentials fit into your network

The first decision is whether n8n runs as a single main instance or in queue mode. A single main instance receives webhooks, schedules triggers and executes workflows itself, which may be enough for a pilot of migrated flows. In queue mode, the main instance still handles triggers and webhooks, but it hands executions through Redis to a pool of worker processes, and those workers read and write workflow data in PostgreSQL. Map each Power Automate flow's trigger type to this design before you size anything: flows that start from an inbound HTTP request need a webhook endpoint reachable by the calling system, while scheduled flows only need the main instance and its workers to reach the database and Redis.

Credentials are the part most often misconfigured. n8n stores connection credentials encrypted in the PostgreSQL database, and the encryption key from the main instance must be shared with every worker and webhook processor so they can decrypt those credentials. Store that key in your secrets manager, restrict who can read it, and confirm that a rotation plan exists before go-live, because a worker started with the wrong key cannot use any stored connection. Also confirm that Redis and PostgreSQL sit on private network segments with no public exposure, since queue traffic and credential rows are the two most sensitive data paths in the deployment.

High availability and licensing need a legal and architecture check before rollout. Multi-main setup, which runs several main instances for failover, is restricted to Enterprise self-hosted deployments and is not available in the Community edition. Your legal team should confirm which edition fits your use: n8n's LICENSE file places the main codebase under the Sustainable Use License, which covers internal business use but not redistribution or commercial hosting for others, and files with .ee in their name or directory require a valid Enterprise License. Confirm which features you need, such as SAML single sign-on and Git environments, which are listed for Business and Enterprise plans, and get the licensing position in writing before building production flows on any edition.

What drives migration cost and duration

This table lists the components that shape the effort and spend of moving Power Automate cloud flows to n8n, with the driver, how to reduce it and what to request in a written quote. Read each row as a line item to size with your own inventory, because most totals follow from flow count, connector count and the number of owners. Recurring costs for hosting, PostgreSQL and licensing continue after the switch, so ask quotes to separate them from one-time rebuild work.

Component	Why it drives cost	How to reduce it and what to ask for in a quote
Flow count and complexity	Each flow is rebuilt by hand, and branching, loops, error handling and sub-flows add more work than simple trigger-to-action flows.	Triage flows into simple, moderate and complex groups from the inventory. Ask for a per-flow or per-group estimate with stated assumptions.
Connectors and gateway count	Each distinct connector needs its own n8n node or HTTP configuration, and each on-premises data gateway connection needs a replacement network path.	Consolidate duplicate connectors and retire unused flows first. Ask the vendor to list every connector and gateway they expect to rebuild.
Number of owners to interview	Flows are owned by individuals, so each owner must confirm intent, data sources and who depends on the output.	Agree an owner list from the inventory and interview owners in batches. Ask for the number of interviews and review sessions included.
Credential re-creation	Power Automate connections do not carry over, so every account, service principal and API key must be issued again in n8n with the right scopes.	Maintain a credentials register with owner and scope. Ask who obtains and stores each secret and how rotation is handled.
Testing and parallel run length	Each rebuilt flow needs test cases, comparison against the original output and a period where both platforms run together.	Define acceptance criteria per flow before work starts. Ask for the length of the parallel run and who signs off the switch-off.
n8n hosting and PostgreSQL operations	Self-hosted n8n needs servers, a PostgreSQL database, backups, patching and monitoring, and queue mode adds Redis and worker capacity for higher load.	Size from expected execution volume and plan growth. Ask for infrastructure in your cloud or data center, backup retention and who is on call.
Licensing edition	The Community edition runs without a license key. Business and Enterprise editions add SSO, LDAP, Git environments, log streaming, multi-main high availability and support, and n8n's pricing page lists Business at 667 euros per month billed annually and Enterprise at custom pricing.	Confirm which features your controls require, then compare editions. Ask the quote to show each edition separately and to name the n8n pricing page as the source of list prices.
Training	Makers used to the Power Automate designer need time to learn n8n's canvas, expressions and credential model, and reviewers need to read the new workflows.	Train a small group of makers who then coach others. Ask for the number of training sessions and the materials that will be handed over.

How the migration differs by starting point

A small team usually has a modest number of cloud flows, most of them built by individual makers in a shared or personal environment. The inventory is short enough to complete by hand, and the main risk is that flows exist only in one person's account. Start by asking every maker to list the flows they own, the triggers they depend on and the business process each flow supports.

Owner-level inventory: Record the owner, the environment and the last time each flow ran, so you can skip flows that no longer execute.
Single-flow exports: Owners can export individual flows as packages. Keep these as reference files, since they do not import into n8n.
Rebuild by hand: With few flows, rebuilding each trigger and action in n8n is practical and gives makers a chance to remove steps that no longer matter.
Personal connections: Connections often use an individual's account. Plan to re-create them under a service account that the team controls.
Informal approvals: Change control may be a chat message. Write down who agreed to each cutover date.

Before switching off a flow, confirm with its owner which runs must still complete during the parallel period.

What usually goes wrong and how to prevent it

Most failed Power Automate to n8n migrations break in the same few places: ownership, credentials, error paths, endpoints, queue configuration and licensing. Each card below names one of these risks and the check to run before the old flow is switched off.

Flows stop when an owner leaves

Power Automate flows often run under the account of the person who built them, and orphaned flows can stop without anyone noticing. When the same happens in n8n, scheduled workflows and credentials tied to a departed user's identity fail quietly. During the inventory, record the owner, the environment and the business purpose of each flow, then assign a named team owner in n8n before cutover. Confirm that the schedule and trigger still fire under a service identity.

Credentials not re-created

Exports carry the logic of a flow but not the secrets that authenticate it. Each connection to a SaaS app, database or API must be created again in n8n with a credential owned by the migrated team, and scopes should match what the old connection used. A workflow that imports cleanly can still fail on its first run. Test every credential with a live call from the target environment and keep a register of which secret belongs to which workflow.

Missing error handling

Power Automate flows often rely on run-after settings and retry policies that teams never documented. A migrated n8n workflow that has no error branch will stop on the first failed node and report nothing to the people who need to act. Map each run-after path to an explicit error branch, decide which failures retry and which alert a person, and route alerts to a shared channel rather than one maker's inbox. Test with a deliberately broken credential before go-live.

Webhook URLs change and break upstream systems

Trigger URLs in n8n are generated per workflow and differ from the HTTP endpoints that Power Automate issued. Any upstream system, form, or partner that posts to the old URL will fail after cutover. Inventory every inbound caller before migration, update each one to the new endpoint in a controlled change, and keep the old flow running until the callers have switched. Confirm the public hostname and TLS certificate are stable so the URL does not change again later.

Encryption key mismatch in queue mode

In n8n queue mode, the main instance hands executions to workers through Redis, and the workers read credentials from PostgreSQL. Those workers must have the same encryption key as the main instance, or they cannot decrypt stored credentials and executions fail. Set the key once in a secrets store, deploy it identically to the main, worker and webhook processes, and record where it is kept so a rebuilt node does not generate a new one. Test a worker restart before relying on queue mode.

Licensing misread for internal versus commercial use

n8n's main codebase is under the Sustainable Use License, which permits use for your own internal business purposes or non-commercial use, and files with .ee in their name require a valid Enterprise License. Teams that offer n8n-powered automation to customers, resell it or host it as a service can fall outside internal use. Before migration, have legal review the intended use, confirm that no .ee code is deployed without a license, and document the decision. Ask n8n to confirm any edge case in writing.

Questions buyers ask before migrating from Power Automate to n8n

Can we migrate Power Automate flows to n8n in-house?

Yes, many teams do, provided they have someone who can read the existing flows, rebuild each trigger and action in n8n, and operate the server afterward. The work splits into three parts: inventory and triage, rebuilding flows, and running the new platform. The first part is mostly a people task, since owners must confirm what each flow does and whether anyone still uses it. The second depends on how many flows use Microsoft 365 connectors, custom connectors and on-premises data gateway connections, because each one needs a replacement n8n node or HTTP call and fresh credentials. The third is ongoing: patching, backups, PostgreSQL and encryption key handling. Be honest with yourself about whether that capacity exists before committing.

What drives the cost and time of a Power Automate to n8n migration?

The main drivers are the number of flows, how many of them are business critical, how many depend on connectors that have no direct n8n equivalent, and how many touch on-premises systems. Costs fall into one-time work (inventory, rebuilding, testing, cutover) and recurring work (hosting, PostgreSQL, upgrades, monitoring, and any n8n license tier you need). On the licensing side, n8n's pricing page lists a free self-hosted Community edition and a Business plan at 667 euros per month billed annually, which is currently self-hosted only, and Enterprise at custom pricing. Features such as SSO and LDAP, environments with Git, and log streaming sit in the Business and Enterprise plans. Ask any partner for a written scope that names the flow count, connector list and environments before comparing quotes.

Do Power Automate exports import directly into n8n?

No. Power Automate exports, whether single-flow packages or Dataverse solutions, are written for Microsoft's platform and do not import into n8n as working workflows. Treat them as a reference: they show the trigger, action sequence, conditions, expressions and connection names you must reproduce. The reliable path is to document each flow, rebuild it as an n8n workflow, and test it against the same inputs. Credentials will not carry over, so every connection must be recreated in n8n with the account and scopes the flow needs. Keep the exported files in version control so the reference survives after the Power Automate licenses lapse.

How does running n8n and Power Automate in parallel work?

Run both platforms side by side for each flow group, with one trigger active at a time, until the n8n version produces the same results. Start with low-risk, read-only or notification flows, then move flows that write data. For each flow, compare outputs over a set period, log differences, and agree the cutover date with the flow owner. Disable the Power Automate flow only after the n8n version is confirmed, and keep the export for rollback. Watch for duplicate side effects, such as two systems sending the same email or creating the same record, because both platforms can react to the same event. Document who signs off each cutover.

What does an on-premises data gateway replacement require in n8n?

The on-premises data gateway in Power Automate lets cloud flows reach internal databases and file shares. In n8n, the equivalent is to run the n8n instance, or a worker, inside your network so it can reach those systems directly, which means your data never leaves the network. You need to decide where the n8n main instance and workers sit, open only the paths they need, and create database credentials that follow least privilege. Confirm the connector behavior against your own systems, since n8n's node coverage for a given database or file share should be checked in the current docs rather than assumed. Gateway replacement is often the step that changes the hosting design the most.

Do we need a partner to migrate from Power Automate to n8n?

A partner is not required, but one is useful when the flow estate is large, when flows touch regulated data, or when the internal team cannot take on rebuilding and operating n8n at the same time. DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts. Ongoing support and upgrades are available as retainers. DeployOpen does not publish a price list, so a quote follows from the written scope. Ask any provider to show how they handle inventory, parallel running and rollback before you sign.

Which n8n license terms should we check before switching?

Check the license before you deploy in production, because n8n's main codebase is under the Sustainable Use License. That license allows use or modification for your own internal business purposes or for non-commercial or personal use. Files with .ee in their name or directory are not covered and require a valid n8n Enterprise License. Confirm with n8n how these terms apply to your organization, especially if you plan to offer automations to customers or other companies. The Community edition runs without a license key, while adding a Business or Enterprise license key enables those editions. Involve legal or procurement early, since the license decision affects both cost and what you can build.

How DeployOpen scopes, runs and supports the migration

DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside your own infrastructure, so an n8n migration starts with a written scope covering your flows, connections and environments. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before any work begins.

How we scope

Inventory of Power Automate cloud flows by owner, environment and connector, agreed before any rebuild starts
Decision list for each flow: rebuild in n8n, keep in Microsoft 365, or retire, recorded in the written scope
Mapping of on-premises data gateway connections to the network paths and n8n hosting you will use
Named deliverables, acceptance criteria and timelines for each flow group, confirmed in writing

How we build

Self-hosted n8n deployed in your cloud account, data center or air-gapped network, as agreed in scope
Rebuilt triggers and actions tested against exported flow definitions used as a reference, not a copy
Credentials re-created in n8n with the encryption key handled according to your secrets process
Side-by-side test runs of each rebuilt flow against the original before any cutover is approved

How we hand over

Documentation of each rebuilt workflow, its owner, its connections and its failure handling
Runbook covering backups, upgrades, scaling and the edition and license choices your team must make
Cutover checklist with a rollback path for each flow group, signed off by your flow owners
Training for your administrators on operating n8n, credentials and environments after handover

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover
Retainer scope agreed in writing, covering the platform, the flows you migrated and new integrations
Routine review of n8n release notes and planned upgrades, scheduled with your change process
Clear ownership split between your team and DeployOpen, defined in the handover documentation

Migrate from Power Automate to n8n