How to Migrate From n8n to Activepieces
n8n changed its license in 2022 from Apache 2.0 to the Sustainable Use License, which restricts commercial use of the self-hosted version if you offer it as a service to third parties. For internal automations, this doesn't affect most teams. But for companies building products on top of workflow automation, or for agencies managing automations for clients on shared infrastructure, the license creates legal ambiguity that some legal and compliance teams won't accept.
Activepieces is MIT-licensed. That's the primary reason teams move to it from n8n, and it's a clean, unambiguous one. The secondary reason is the UI: Activepieces has invested in a builder experience that's polished and accessible to non-engineers. Teams that want to hand workflow maintenance to operations or marketing staff find Activepieces easier to onboard. The "pieces" (their term for nodes/steps) follow a consistent pattern that makes adding integrations less surprising.
What's actually different
Both tools are self-hosted, visual workflow builders with a trigger-plus-steps model. The differences are mostly in license, UX philosophy, and depth of feature set.
| Dimension | n8n | Activepieces |
|---|---|---|
| License | Sustainable Use (non-commercial SaaS restriction) | MIT |
| Deployment | Docker, npm, cloud | Docker, cloud |
| Code execution | Code node (JS/Python) | Code step (TypeScript) |
| Visual builder | Canvas-based | Linear step builder |
| Integration count | 400+ nodes | 200+ pieces (growing) |
| Error handling | Error Trigger workflow | Flow-level error handling |
| Self-host complexity | Moderate | Low to moderate |
| Multi-user access | Enterprise plan for full RBAC | Included in open source |
The license is the headline difference, but the UX difference is real too. n8n uses a free-form canvas where you drag and connect nodes. Activepieces uses a more structured, vertical step builder. For complex workflows with many branches and merges, n8n's canvas can display the logic more clearly. For straightforward linear flows, Activepieces's step model is easier to scan and maintain.
Multi-user features are worth noting. n8n's self-hosted version has team features, but full role-based access control (RBAC) requires the Enterprise plan. Activepieces includes multi-user support with project-level access control in the open-source version, which matters for teams with multiple people managing automations.
Mapping your existing workflows
n8n and Activepieces share enough conceptual vocabulary that the translation is fairly direct.
An n8n workflow becomes an Activepieces flow. Both are triggered by a single trigger and execute steps in sequence (with branching possible).
An n8n trigger node maps to an Activepieces trigger. Activepieces has triggers for webhook, schedule, and app events. The same categories as n8n, with similar configuration options.
An n8n HTTP Request node maps to Activepieces's HTTP Request piece. Parameters are similar: URL, method, headers, body. For APIs that don't have a dedicated piece, this is your fallback.
An n8n IF node maps to Activepieces's Branch step. The Branch step splits flow execution based on conditions. In Activepieces, you define conditions using a visual condition builder rather than expressions. For teams that prefer a GUI over writing {{ $json.status === 'active' }}, this is a friendlier interface.
An n8n Switch node (multiple branches) maps to Activepieces's Router piece, which routes execution to different branches based on conditions. Each branch can have its own steps.
An n8n Code node maps to Activepieces's Code step. Activepieces's code step runs TypeScript (compiled to JavaScript). If your n8n Code nodes use JavaScript, the migration is straightforward. Python code nodes in n8n don't have a direct equivalent in Activepieces; those logic blocks need to be rewritten in TypeScript or replaced with piece configurations.
An n8n Set node maps to Activepieces's data passing between steps. In Activepieces, you reference previous step outputs directly in the configuration fields using {{ stepName.output.fieldName }} syntax. The Set node's field-mapping functionality is handled inline rather than as a dedicated step.
n8n sub-workflows (workflows that call other workflows) have a partial equivalent in Activepieces via flow triggers and the ability to chain flows, though the approach differs in implementation.
The actual migration steps
Step 1: Export your n8n workflows as JSON. In n8n, go to each workflow and use the Export option to download the workflow as a JSON file. This gives you a readable representation of every node, connection, and configuration. Store these in version control; they're your source of truth during migration.
Step 2: Audit your n8n node usage. Go through your exported JSON files (or inspect each workflow in the UI) and list every node type you use. Cross-reference against Activepieces's piece library to identify any nodes that don't have a direct equivalent. These are the workflows that need the most attention.
Step 3: Deploy Activepieces. Activepieces's Docker deployment is well-documented. The standard docker-compose.yml from their repository sets up the app, database, and queue service. Set your environment variables, run the compose file, and you have a working Activepieces instance. The setup is generally simpler than n8n's self-hosted config.
Step 4: Set up connections. In Activepieces, go to Connections and authenticate each service you use. Like n8n, these are stored in Activepieces's credential vault. OAuth flows work the same way; API keys are entered manually.
Step 5: Rebuild a pilot flow. Choose a representative workflow and rebuild it in Activepieces. Work through each step, referencing your n8n JSON export for the original configuration. Test the flow with real data and compare outputs.
Step 6: Handle webhook URL updates. For any n8n workflow triggered by an incoming webhook, Activepieces will generate a new webhook URL. Before switching off the n8n workflow, update every external service that posts to the n8n webhook URL.
Step 7: Migrate incrementally. Work through your inventory systematically, deactivating n8n workflows only after their Activepieces equivalents have run in production successfully.
Gotchas you'll hit
Piece coverage gaps exist. Activepieces has 200+ pieces but n8n has 400+ nodes. Some niche integrations you use in n8n may not have a dedicated Activepieces piece. The HTTP Request piece is your fallback, but it requires more manual configuration than a purpose-built piece.
Python code nodes don't transfer. If your n8n workflows use Python in Code nodes, those need to be rewritten in TypeScript for Activepieces. Budget time for this if it applies to your workflows.
Expression syntax is different. n8n uses {{ $json.field }} and {{ $('NodeName').item.json.field }}. Activepieces uses {{ stepName.output.field }}. The concepts are the same but the syntax differs. Update all data references as you rebuild each flow.
Canvas vs linear builder is a workflow design change. Complex n8n workflows with many parallel branches and merges are harder to express in Activepieces's step builder. You may need to restructure some workflows that relied on n8n's flexible canvas layout.
Webhook URLs change. Same as any migration: external services pointing to n8n webhook URLs need updating. Make a thorough list before you start.
Error handling requires reconfiguration. n8n's error handling uses a dedicated Error Trigger workflow. Activepieces handles errors at the flow level with a different configuration pattern. You'll need to set up error handling fresh in Activepieces; it doesn't transfer from n8n's error workflows.
When NOT to switch
Staying on n8n makes sense in several situations.
If you're using n8n for internal automation with no intent to offer it as a service, the license restriction doesn't affect you. The Sustainable Use License is fine for internal tooling.
If your workflows make heavy use of n8n's Code nodes in Python, the rewrite effort for TypeScript is real. Factor this into your decision.
If your team has invested in n8n's canvas model for complex workflow visualization, Activepieces's linear builder is a step backward in expressiveness for intricate branching logic.
If you rely on specific n8n nodes that have no Activepieces equivalent and no clean API fallback, those workflows will require extra engineering work.
The license clarity is a legitimate reason to migrate, and for teams with non-technical users managing flows, Activepieces's UX polish is a genuine quality-of-life improvement. The migration itself is methodical: export, audit, rebuild, validate, cut over.
The piece coverage gap and the Python code node issue are the main risks to assess before committing. If neither applies to your workflows, the migration is straightforward.