Migration
Power Automate to n8n migration service
Most teams asking about this move are answering a licensing review, not a missing feature. Power Automate flows run only on Microsoft's cloud, under Microsoft's licence tiers, and the moment a flow needs a premium connector, a raw HTTP call or more headroom than its plan allows, the licence starts deciding the design.
n8n is the other end of that trade: a workflow platform you can self-host on your own server or run on n8n's cloud, with code nodes and an HTTP node available everywhere and no premium tier per connector. Our Power Automate to n8n migration service is the path between the two. We document every flow you have, rebuild the ones worth keeping in n8n by hand, run each rebuild beside its original until the outputs agree, and tell you plainly which flows should stay in Microsoft because their value lives inside Microsoft 365. A cheaper platform that drops an approval or double-sends an invoice is not cheaper.
The case for moving
Why do teams move flows from Power Automate to n8n?
Usually because licensing is shaping the automation. Premium connectors, per-user or per-flow plans and Power Platform request limits decide what is affordable to build in Power Automate. n8n runs on a server you control or on n8n's own cloud with no per-connector tier, so the constraint becomes engineering effort rather than licence arithmetic.
The licence is the first thing to read, not the flows. Microsoft 365 plans include Power Automate with standard connectors — Outlook, Teams, SharePoint, OneDrive, Excel — which is why so many organisations have dozens of flows nobody budgeted for. The line is crossed by a premium connector: the generic HTTP action, SQL Server, Dataverse outside its seeded uses, or a custom connector to your own API. From there each maker needs a premium licence or each flow needs a per-flow licence, and Microsoft publishes limits on actions, loops, run duration and throughput (opens in new window) that vary with the plan. None of that is unreasonable. It is simply a cost model where the shape of the work, not its volume, sets the bill.
n8n inverts that model. Self-hosted, it is software you run under its fair-code licence on infrastructure you choose, as set out in n8n's hosting documentation (opens in new window); on n8n's cloud it is billed by executions, where one run counts once however many nodes it passes through. Either way the HTTP Request node and the JavaScript and Python Code nodes are part of the product, so a flow that needs to call an undocumented endpoint or reshape a payload does not trigger a licensing conversation. What you take on in exchange is the operating work Microsoft was doing for you: hosting, upgrades, backups and credential governance.
If you have not settled whether to move at all, our n8n vs Power Automate comparison argues that choice on its merits. This page assumes the decision is made, or nearly made, and covers how the move is done safely.
| Dimension | Power Automate (cloud flows) | n8n |
|---|---|---|
| Hosting model | Microsoft's cloud only, inside your Microsoft 365 tenant and its environments | Self-hosted on a server you control, or n8n's managed cloud |
| Pricing model | Standard connectors included with Microsoft 365; premium connectors need per-user or per-flow licences | Cloud plans billed by executions per month; self-hosted community edition carries no licence fee, with paid tiers for enterprise features |
| Node and action limits | Published caps on actions per flow, nesting depth, loop concurrency and Power Platform requests per 24 hours, set by licence | No cap on nodes per workflow; the practical limits are your server's memory and the execution timeout you configure, or your cloud plan's quotas |
| API flexibility | The HTTP action and custom connectors are premium; expressions use Microsoft's workflow definition language | HTTP Request node and JavaScript or Python Code nodes in every edition; expressions are JavaScript |
| Microsoft 365 integration | Native, signed in as the user, with triggers inside Teams, Outlook, SharePoint and Power Apps | Nodes for common Microsoft 365 services plus Microsoft Graph over HTTP, via an Entra ID app registration |
| Error handling | Scopes with configure-run-after settings, and run history in the portal | Per-node error outputs and a dedicated error workflow that can alert, log and hold the failed item |
| Governance | Power Platform data loss prevention policies, environments and tenant admin controls | Whatever you configure: users and roles, credential sharing, and the network the server sits on |
| Version control | Solutions and environment pipelines, managed in Microsoft's tooling | Workflows are JSON you can export, diff and keep in your own repository |
Moving a flow moves it out of your governance, too. Power Automate flows sit under the tenant's data loss prevention policies (opens in new window), which decide which connectors may share data. An n8n instance is outside them. Who may edit workflows, who may see credentials, and which systems a workflow may write to all need deciding again — before the first flow crosses, not after an auditor asks.
Sequence
How does a flow move from Power Automate to n8n?
In four stages: every flow is inventoried and documented, the ones worth keeping are rebuilt in n8n by hand, each rebuild runs beside its original until the outputs agree, and flows whose value lives inside Microsoft 365 are recommended to stay where they are. Nothing is switched off until its replacement has been seen working on real traffic.
1. Flow inventory and documentation
Flows in Power Automate are owned by people, not by the organisation, which means some of the most important ones live in the account of somebody who left last year. The inventory starts from the tenant's admin view rather than from anyone's memory: every flow in every environment, with its owner, trigger, connectors, connection accounts and last successful run. Each one is then exported and read. The export is the precise record of what the flow does, including the condition somebody added after a bad week and the expression quietly fixing a date format. Dead and duplicate flows are retired at this stage, because rebuilding them would be paying to move waste. What comes out is a written specification per flow, and it is yours whether or not the migration goes ahead.
2. Rebuilding in n8n — reconstruction, not import
There is no converter, and there could not be a faithful one. A Power
Automate export describes a flow in Microsoft's workflow definition
language — the same one Azure Logic Apps uses — with Microsoft
connectors and expressions such as triggerBody() and
items('Apply_to_each'). n8n works differently enough that
each flow has to be reconstructed: an Apply to each loop usually
disappears, because n8n passes lists of items through nodes natively;
a scope with run-after settings becomes an explicit error output or an
error workflow; a Teams or Outlook approval becomes a message plus a
Wait node that resumes when somebody answers. Expressions are rewritten
in JavaScript, and connections are re-authorised rather than copied, so
every credential is a deliberate decision about scope and ownership.
The rebuild is also where undocumented behaviour gets written down — if
it is not in the specification, it is not in the new workflow.
3. Side-by-side validation
Each rebuilt workflow runs beside its original on the same real triggers, with its write steps disabled or pointed at a test target, until the outputs match. Disagreements are the useful product of this stage: they are almost always logic the original was doing that nobody knew about. How long a flow stays in parallel depends on how often it fires — a flow that runs on every new email proves itself in days, one that runs at month-end needs a month-end. Cutover is then per flow: n8n takes the trigger, the Power Automate flow is turned off but kept, and only after a quiet period is anything deleted or a licence reduced.
4. The hybrid recommendation
Some flows should not move, and the recommendation says which ones and why. Where a flow's value comes from living inside Microsoft's own surfaces — a button in Power Apps, an approval card in Teams, a desktop flow driving a legacy application — moving it swaps a native integration for a hand-built one. The two platforms coexist without trouble: n8n can start a Power Automate flow through its HTTP request trigger, and a Power Automate flow can call an n8n webhook, so the Microsoft-native edge can stay in Microsoft while the heavy logic runs in n8n.
The honest part
Which flows should stay in Power Automate?
Flows that live inside Microsoft's own surfaces: desktop flows doing robotic process automation, flows started from Power Apps or a SharePoint button, approvals answered in Teams or Outlook, and anything bound to Dataverse or a business process flow. Moving these swaps a native integration for a hand-built one, and that trade rarely pays.
| Flow type | Recommendation | Why |
|---|---|---|
| Scheduled jobs moving data between systems | Move | The clearest win: often premium-connector work, and n8n handles batching, retries and logging well |
| Webhook and API integrations with non-Microsoft systems | Move | The HTTP action is premium in Power Automate and free-standing in n8n, and the logic usually belongs nearer the systems it joins |
| Flows with heavy transformation or AI steps | Move | Code nodes replace long chains of compose and expression actions, and the result is readable and testable |
| Email, Teams and SharePoint notifications | Either | Both platforms do this well; move them only if they belong to a larger workflow that is moving anyway |
| Approvals answered in Teams or Outlook | Usually stay | The native approval experience is hard to equal; a rebuild works but the people approving will notice |
| Flows triggered from Power Apps or SharePoint buttons | Stay, or hybrid | The trigger lives in Microsoft's interface; keep a thin flow there that hands the work to n8n if the logic is heavy |
| Dataverse and business process flows | Stay | Bound to the Power Platform data model; moving them means moving the application they serve |
| Desktop flows (robotic process automation) | Stay | n8n has no desktop automation equivalent; these drive screens, not APIs |
You own the result outright: workflows exported as JSON, credentials in your accounts, the per-flow specification from the inventory, and a runbook naming who is alerted when something fails. If your own team would rather run the rebuild, we will set up the instance and the conventions and stay on as backup. And if the honest answer on the call is that your flows are fine where they are, that is what you will hear.
Where this sits next to the rest of the work
If most of your estate turns out to belong in Microsoft, the better project is improving it in place, which is the work of a Microsoft Power Automate consultant. Once n8n is the platform, an n8n workflow automation consultant covers the build, repair and monitoring that follows the move, and our guide to n8n cloud vs self-hosted settles where the new instance should run. If the platform you are leaving is Zapier or Make rather than Microsoft, the Zapier to n8n migration and Make.com to n8n migration pages cover those routes, and how engagements work explains how a scope is agreed before any of it starts.
Questions
What teams ask before moving flows off Microsoft
Why not just keep Power Automate?
Often you should. If your flows mostly connect Outlook, Teams, SharePoint and Excel, run on standard connectors and sit inside licences you already pay for, moving them buys very little. The case for n8n starts when premium connectors, per-flow licensing, platform limits or the need to host the automation yourself begin deciding what gets built.
How long does a Power Automate to n8n migration take?
It depends on how many flows you have and how much logic hides inside them, which is why the inventory comes first and the estimate follows it. The side-by-side run also sets a floor of its own: a flow that fires once a month cannot be validated until a month-end has passed through both versions.
What happens to our Microsoft 365 integrations?
They keep working through a different door. n8n has nodes for the common Microsoft 365 services and reaches the rest of Microsoft Graph through its HTTP Request node, authenticated by an app registration in your own Entra ID tenant. That registration needs admin consent, so your Microsoft administrator is involved from the first week rather than the last.
Can our flows be imported into n8n automatically?
No. A Power Automate export describes each flow in Microsoft's workflow definition language, with Microsoft connectors and Microsoft expression functions, and n8n has no importer for it. The export is still valuable as an exact specification to rebuild from, but every flow is reconstructed by hand and then tested against the original.
Free consultation
Tell us what is costing you the most time
Describe the process. You get a straight read on whether it is worth automating, roughly what it would take, and what we would tackle first — on a call that costs nothing.
- Under an hour, free, and no obligation
- Fixed price per stage, agreed before any work starts
- You own everything we build, documented and in your accounts
- If you do not need us, we will say so on that call
The form is the fastest way to reach us — we reply from a real person, usually within one business day.
Still deciding between the two platforms? Read the n8n vs Power Automate comparison.