Migrate from Workato to n8n

Moving Workato recipes to self-hosted n8n Enterprise is a rebuild with a clear inventory, not a file import. This page plans the sequence, the on-prem connections, SSO and environments, and the license terms.

On this page

Migrate from Workato to n8n: what the move involves

Recipes are rebuilt on n8n using the exported packages as the specification, not imported. Workato's recipe lifecycle management export gives you the JSON recipe and dependency files you need to document each flow, its triggers, actions and lookup data, before anyone builds anything in n8n. Most teams that move do so at a renewal, because the cloud cannot reach a private network, or because the whole runtime has to stay in their own infrastructure. In each case, the work is a rebuild performed by integration engineers, often with an implementation partner who handles hosting, hardening and handover. Expect the effort to scale with the number of recipes, the number of custom connectors and how many on-prem connections each flow depends on.

Connections are the part most likely to slip. Workato's on-prem agent makes only outbound connections to Workato, so the private systems it reached were configured around that agent. In n8n you will need to recreate each credential, decide how private endpoints are reached from the n8n main instance and workers, and confirm that each integration node covers the actions the recipe used. Use the exported packages as a checklist: every recipe step should map to a node, a custom HTTP call or a documented gap. For SSO and environments, plan for the Business or Enterprise tier, since SAML single sign-on and Git-based environments are not in the Community edition. Confirm current feature availability on n8n's pricing page before you commit to a tier.

n8n is source-available under the Sustainable Use License, not OSI open source. The license permits use for your own internal business purposes, but it does not allow you to offer n8n as a service to others, and files with .ee in their name need a valid n8n Enterprise License. Ask legal to review the license against how you intend to use it, including any partner or contractor access and any internal platform team serving other business units. Also confirm the license terms for the version you deploy, since they are set by the n8n LICENSE file in the repository. Keep the decision and the review on record before the first production recipe is rebuilt.

Which Workato capabilities map cleanly to n8n and which need rework

This table compares the Workato capabilities an integration team depends on with their n8n counterparts. In the Fit column, clean means the capability carries over with configuration, needs rework means the flow, network or licensing design must be rebuilt, and gap means n8n needs a different component. Several rows depend on your n8n edition, so confirm licensing before you plan the migration.

Workato capabilityn8n equivalentFit
Scheduled and webhook triggersSchedule and webhook trigger nodes in self-hosted workflowsClean
Recipes as multi-step flowsWorkflows built on the canvas, with code nodes for custom logic; each recipe is rebuiltNeeds rework
Connectors to SaaS applicationsBuilt-in integration nodes, with HTTP requests for gaps; confirm each app and action you useNeeds rework
On-prem agent connectivitySelf-hosted n8n inside your network; the agent's outbound-only TLS tunnel needs a new network designNeeds rework
Error handling and retriesError workflows and node retry settings; test failure paths against your current recipe logicNeeds rework
SSO and user managementSAML single sign-on on Business and Enterprise plans; not available on CommunityNeeds rework
Environments and version controlEnvironments with Git are included only in Business and Enterprise plansNeeds rework
Audit logging and API-published recipesLog streaming on Business and Enterprise; API keys and rate limits need a separate gatewayGap

How lifecycle management packages become the migration inventory

The recipe lifecycle management export is the starting inventory for this migration, and it should be captured before anyone plans n8n workflows. The package has two parts: a manifest that lists what was exported, and a zip of JSON files containing each recipe and its dependencies. Read the manifest first and confirm that every recipe your team considers live appears in it. Check whether lookup table data is included in the package, because a recipe that depends on a lookup table will not be fully described without it. Record the export date and the Workato environment it came from, so the inventory can be reconciled against recipes that change later. For the privileges required and the export steps, use the export how-to page in this series.

Once the inventory is complete, sort every recipe along four dimensions: owner, business process, connection type and runtime dependency. Owner tells you who signs off on the rebuild and who tests it. Business process groups recipes that must cut over together, such as order-to-cash or employee onboarding. Connection type shows which SaaS apps and credentials must be recreated in n8n, which is a separate step because connections are not portable between platforms. Runtime dependency is the most important column for this topic: flag any recipe that reaches a private system through the on-prem agent, since those workflows need an n8n instance placed where it can reach the same systems. Recipes that share a dependency are usually the best pilot candidates.

Treat the package as the specification for rebuilding flows, not as a file to import. The JSON describes Workato step types, connector actions, data mappings, branches and error handling, and n8n does not read that format. For each recipe, write a short design brief that lists the trigger, each action, the conditions, the transformations and what happens on failure, using the JSON as the source of truth. Where a Workato connector action has no direct n8n node, record the gap and decide whether to use an HTTP Request node, a community node or custom code. Illustrative example: a recipe with three branches and one lookup table becomes a brief with three branch conditions and a documented table source before anyone opens the n8n canvas.

What data and integrations move, and what you rebuild

A Workato migration to n8n moves logic and documentation, not runtime credentials or live connections. Each card below marks one part of the estate, what it becomes in n8n, and what your team must confirm before cutover.

Recipe logic becomes n8n workflows

Each Workato recipe is a set of triggers, actions, conditions and data mappings. In n8n these become workflows built from nodes on a canvas, with the same steps rebuilt by hand or by an engineer who reads the exported JSON as the specification. Map every recipe to an owner, a trigger type and a target workflow before work starts. Check that error handling and retry behavior match what the business expects, since the two platforms do not configure these the same way. Treat the export as a specification, not an import file.

Lookup table data needs a confirmed path

Recipes often depend on lookup tables that hold reference values such as routing codes, cost centers or currency maps. Confirm with Workato whether the recipe lifecycle management package carries lookup table data and in what form before you plan the rebuild. Where data is included, decide whether it lands in PostgreSQL, a spreadsheet or inside workflow logic. Where it is not included, extract it separately and record who approved each value and when it was last changed.

Credentials are recreated, never copied

Workato connections hold OAuth tokens, API keys and service account passwords that should not leave the platform. Plan to create new credentials in n8n under dedicated service identities with the least privilege each workflow needs. Store them with the encryption key managed by your team, and rotate the source credentials as part of the cutover. Keep a list of every connection, its owner and the system it reaches, since the export does not give you a substitute for that inventory.

On-prem connections rebuilt on your network path

Workato reaches private systems through an on-prem agent that makes outbound TLS WebSocket connections to the cloud and needs no inbound firewall ports. n8n has no equivalent agent, so each private system must be reached from the n8n network path you operate, whether through the host, a worker placed beside the internal system, or a reverse proxy. Confirm firewall rules, DNS and certificate trust for every internal endpoint, and test each connection from the same zone where production workers will run.

Webhooks and triggers get new URLs

Any recipe started by a webhook, a poll or an inbound callback from a SaaS vendor has a Workato endpoint that other systems already call. In n8n each webhook trigger gets its own URL, which you must register again with every calling system. Plan a cutover window in which both platforms accept events, or the callers will drop them. Check that polling triggers do not run twice during overlap, and confirm how each source system retries failed deliveries.

API-published recipes handled separately

Recipes exposed as APIs carry consumers, keys and request volumes that n8n does not manage as a gateway would. Do not move these within the recipe rebuild. Inventory which recipes are published, list their callers and agree a separate plan for authentication, rate limits and versioning. The companion page on self-hosted API gateways covers that work. Until it is complete, keep these endpoints running on Workato so no downstream consumer loses service.

Migration sequence from inventory to decommission

This sequence moves Workato recipes into self-hosted n8n in controlled stages, so each recipe is inventoried, proven on a low-risk flow, run in parallel, cut over with a rollback path, and retired only after evidence is kept. Each step produces a artifact that the next step depends on.

  1. Build the scored recipe inventory

    Start from the recipe lifecycle management packages you export from Workato, which include the recipe JSON and dependency files. The integration lead, with the owner of each business process, reviews every recipe and records its trigger type, connectors, on-prem connections, lookup table use, schedule, volume, data classification and business owner. Score each recipe on complexity, risk and dependence on private systems. The output is a scored recipe list that ranks recipes from simplest and lowest risk to most complex, and marks which ones depend on the on-prem agent and which have no known owner. Recipes without an owner stay out of later steps until someone accepts them.

  2. Pilot one low-risk, internal recipe

    Pick a recipe from the top of the scored list that is not customer-facing, does not write to financial or regulated records, and has a clear owner. Rebuild it in n8n Enterprise on a non-production instance, recreating each connection with service accounts and reaching private systems through a network path your security team has approved. Write an acceptance test before building: the inputs to send, the expected outputs, the error cases and the timing you need. Run the test in both systems. The output is a signed acceptance record showing that the n8n workflow passed every test case, with the Workato results attached as the reference.

  3. Run both systems in parallel

    For each migrated recipe, run the Workato and n8n versions side by side for a period the process owner agrees on in advance. Disable the duplicate trigger in one system at a time so the same event is never processed twice, and keep the other system as the record of truth until the comparison is complete. Compare outputs, record counts, error handling and downstream effects in the systems the recipe writes to. Investigate every difference, including timing and retry behavior. The output is a comparison log per recipe with each difference classified as a defect, a known and accepted change, or an expected platform difference.

  4. Cut over by business process

    Move recipes to n8n in groups that belong to one business process, not one recipe at a time, so that a single process does not split across two platforms. Before each cutover, write the rollback criteria: the specific error rates, missed events or data mismatches that trigger a return to Workato, and the person authorized to decide it. Confirm that Workato can be re-enabled without data loss and that n8n credentials, environments and access controls are in place, including SSO and the encryption key handling your queue mode design requires. The output is a cutover record for each process showing the date, the go or no-go decision, the approver and the rollback procedure that was ready.

  5. Retain evidence and decommission Workato

    After every process has run on n8n through an agreed stabilization period, export and store the final Workato packages, run logs, comparison logs, acceptance records and cutover records in your records system. Confirm the retention period with your legal, compliance and audit teams, because it depends on your own obligations. Then disable the Workato recipes, remove the on-prem agent and revoke its credentials and network rules. Close the Workato subscription only after the retention copies are verified. The output is a decommission record listing each recipe, its replacement workflow, the retained evidence location and the approver who signed off on removal.

Running Workato and n8n in parallel without double-processing

The main risk in a parallel run is that both platforms act on the same event, so every trigger that writes to a system of record must have exactly one active owner at any moment. Before either side is enabled, assign each business process to one platform in a written run plan, then disable the Workato recipe triggers or the n8n trigger nodes that belong to the other side. For n8n, a workflow that is saved but not activated does not listen for events, so keep migrated workflows inactive until their process is cut over. Point test-stage n8n workflows at sandbox accounts or test records in the target systems, and confirm that a test record cannot reach production mail, billing or ticketing queues.

Credentials cannot be copied from Workato, so each n8n connection must be recreated with a service account scoped to the same permissions the recipe used. Note which connections the recipe reads on-prem, because those need a reachable network path from the n8n instance, not from a Workato agent. For cost planning, n8n counts one execution per whole workflow run regardless of the number of steps, while Workato bills on its own usage terms, so the same process will show different counts on each side. Compare the expected run volume of each process under both models, and ask your n8n partner or licensing contact to confirm how the counting applies to your deployment.

Compare outputs before any cutover. For each process, run both platforms against the same test inputs and diff the records written, the field mappings, the error messages and the retry behavior. Keep Workato error logs and n8n execution history side by side for at least one full business cycle that includes month-end or the batch windows your process depends on. Define a cutover gate in writing: the named owner, the agreed diff tolerance, the duplicate-write check and the sign-off roles. The rollback path matters as much as the gate. Keep the Workato recipe enabled but paused, record the timestamp of the switch, and document how any records created on n8n during a failed window will be reconciled before the recipe is resumed.

How SSO, environments and the license change the architecture

Workato access is usually managed through its own identity and roles. In n8n, single sign-on through SAML is available on the Business and Enterprise plans, not on the free Community edition. n8n publishes step-by-step SAML setup guides for Okta Workforce Identity and Azure AD, which makes those two identity providers the most direct starting points.

  • Plan dependency: SAML requires a Business or Enterprise license key, so budget for it before you design the access model.
  • Identity providers: Setup guides exist for Okta Workforce Identity and Azure AD. Confirm that your provider's SAML attributes and group claims match what n8n expects.
  • Role mapping: Decide which identity groups become n8n admins, builders and viewers, and test each mapping with a sample account before go-live.
  • Break-glass access: Keep a documented local recovery path so a federation outage does not lock out the platform team.
  • Credential exposure: Users who can edit workflows can often reach the credentials those workflows use, so review who holds build rights.

Before cutover, ask n8n to confirm the SAML features included in your specific license tier and test the full login and deprovisioning path in a non-production instance.

What drives migration cost and duration

This table lists the variables that move the cost and effort of moving Workato recipes to self-hosted n8n, with the reason each one matters and how to keep it down. Use it to build the written scope before asking for a quote, since most of the cost sits in recipe rebuilds, on-prem connections and acceptance testing rather than in the license.

DriverWhy it changes cost or effortHow to keep it down
Recipe count and complexityEach recipe is rebuilt as an n8n workflow, and branching, error handling, lookups and nested logic take longer than simple trigger-action flows. Recipe lifecycle management packages show the real count and dependency depth.Retire unused or duplicate recipes before migration, group similar recipes into shared sub-workflows, and agree a recipe complexity classification in the scope.
Connector coverage gapsn8n advertises more than 1,500 integrations, but a Workato connector without a close n8n equivalent needs a custom HTTP or code node, plus its own testing and credential handling.Map every connector in the package against n8n nodes early, list the gaps, and decide which ones are built, replaced or dropped.
On-prem connection countWorkato's on-prem agent reaches private systems over outbound TLS. In n8n, each private system needs a reachable network path, service accounts and credentials that the team configures and secures itself.Inventory each on-prem connection with its network path, owner and auth method, and confirm firewall and routing changes with the network team before build starts.
Number of environmentsDevelopment, test and production copies multiply configuration, credentials and promotion steps. Environments with Git are included only in n8n Business and Enterprise plans, so promotion work depends on the chosen tier.Limit environments to what the release process needs, parameterize connection settings, and confirm which promotion method the chosen license supports.
SSO and governance requirementsSAML single sign-on is available on n8n Business and Enterprise plans, and audit, role and access controls must be designed, configured and evidenced by the client's team or the implementation partner.Document the role model and approval flow before build, and ask the partner to scope SAML setup against the identity provider named in your environment.
Parallel-run lengthRunning Workato and n8n side by side doubles operating cost for the overlap period and requires reconciliation of outputs. The length is set by business risk, not by the tool.Agree the parallel-run criteria, such as matching outputs for defined transaction types, and set an exit date in the written scope.
Testing and acceptance evidenceEach rebuilt recipe needs test cases, input and output comparison, failure-path checks and sign-off. Evidence requirements from internal audit or external assessors often expand this work.Ask for a test matrix per recipe, reusable test data, and a defined acceptance checklist that the assessor or internal audit has approved.
n8n license tierCommunity is free but lacks SSO, Git environments and multi-main high availability. Business and Enterprise add these features at different prices, and the Business plan is currently self-hosted only. Confirm current terms on the n8n pricing page before budgeting.Match the tier to the requirements list, not to the largest feature set, and confirm in writing which features the chosen tier includes.
Hosting and queue-mode designQueue mode splits triggers, Redis-backed execution and PostgreSQL-backed worker pools. Workers need the shared encryption key, and multi-main high availability is restricted to Enterprise self-hosted deployments.Size the design to actual execution volume, decide whether queue mode is needed at all, and ask the partner to document key handling and backup of the database.
Internal skillsNode.js, JavaScript or Python for custom nodes, PostgreSQL and Redis administration, and identity configuration are needed to run the platform after handover. Gaps in these skills shift cost into ongoing support.Assess the team's skills early, include knowledge transfer and runbooks in the scope, and decide whether support will be retained or handled in-house.

What usually goes wrong and how to prevent it

Most failed Workato to n8n migrations fail in predictable places: the old and new runtimes process the same events, credentials break during recreation, and error paths were never exercised. The cards below pair each risk with one check to run before cutover.

Duplicate processing during parallel runs

While Workato recipes and n8n workflows both listen to the same trigger, a single event can create two tickets, two invoices or two messages. The overlap is most likely with webhooks and polling triggers that point at the same source. Before cutover, decide which side owns each trigger, disable the Workato recipe at the same moment the n8n trigger is enabled, and confirm the source system points only at the new endpoint. Ask the source system owner to confirm where each event is delivered during the overlap window.

Credentials lost during recreation

Workato connections and their secrets do not move with recipe JSON, so every n8n credential must be created again by hand or through a controlled process. Service accounts with rotated passwords, OAuth grants tied to a former user, and API keys copied into workflow fields are the usual failures. Keep an inventory of each connection the recipes used, assign a named owner for each credential in n8n, and store secrets in your approved vault rather than in exported files or chat tools.

Queue-mode encryption key mismatch

In n8n queue mode, the main instance's encryption key must be shared with every worker and webhook processor so they can decrypt credentials from the database. A worker started with a different or missing key will fail executions that touch stored credentials, often only after the main instance looks healthy. Set the same key on all nodes from one secret source, restart each process after changes, and test a credential-backed workflow on every worker before you route production traffic to it.

Connectors missing for an application

Not every Workato connector has an equivalent n8n node with the same actions, triggers and authentication options, and some internal or on-prem applications need a custom HTTP or code step. Build a matrix that maps each application used in the recipes to an n8n node, a generic HTTP request or a custom script, and mark any gap before the rebuild starts. Confirm the on-prem path for private systems in your own network, because Workato's agent model does not carry over automatically.

Untested error paths

Workato recipes often carry retry logic, error handlers and scheduled reruns that teams rarely document, and these paths are the first to break when a workflow is rebuilt. Failed API calls, expired tokens, malformed payloads and partial batch failures can behave differently in n8n. Create test cases for each error branch, compare outcomes with the Workato recipe on the same inputs, and confirm that alerts reach the same on-call channel before the old recipe is switched off.

Licensing assumed to cover distribution

n8n's main codebase is under the Sustainable Use License, which covers internal business use and non-commercial use, but not distribution for commercial purposes. Files with .ee in their name require a valid n8n Enterprise License. Teams that embed n8n in a product they sell to customers, or that offer it as a managed service to other organizations, need legal review before going live. Confirm with counsel how your use case maps to the license text, and record which edition and license key each environment uses.

Questions buyers ask before moving from Workato to n8n

How much does it cost to move from Workato to self-hosted n8n?

The cost is set by components, not by a single fee: n8n licensing, the infrastructure that runs it, the effort to rebuild recipes, and ongoing platform operations. n8n's free Community edition has no license cost, but SSO, environments with Git and log streaming are included only in the Business and Enterprise plans, according to n8n's pricing page. The n8n pricing page lists the Business plan at 667 euros per month billed annually and states that it is currently self-hosted only, while Enterprise is custom priced. Ask for a quote that separates one-time rebuild work from recurring licensing, hosting and support.

How long does a Workato to n8n migration take?

The duration depends on how many recipes you have, how complex they are, how many connectors and on-prem connections they use, and how much testing your processes require. No general timeline is set by a supplied fact, so the reliable way to estimate is to build an inventory first. Start by exporting your recipes with Workato's recipe lifecycle management packages, then count recipes by connector and by dependency. Ask any implementation partner to base its timeline on that inventory and to state the scope and deliverables in writing before work starts.

What does the migration need from our own team?

Your team supplies the business owners who confirm what each recipe must do, the administrators who can export recipes and create connections, and the network and identity staff who provision hosting, the database and SSO. Engineers should be available to validate outputs and to decide how credentials and encryption keys are handled. If you run queue mode, the main instance's encryption key must be shared with every worker and webhook processor so they can read stored credentials, so your security team needs to approve how that key is distributed. Plan for these people's time in the scope document.

Can our own engineers do the migration without outside help?

Yes, a capable internal team can rebuild recipes in n8n, provided it has time, n8n skills and a test process. The main reasons teams bring in outside help are a large recipe count, strict change control, or a need to harden and document the deployment for an audit. Whatever you choose, first confirm which n8n features you need, because multi-main high availability is restricted to Enterprise self-hosted deployments, according to n8n's queue mode documentation. Retainers for upgrades and ongoing support are also available from DeployOpen, and the scope is agreed in writing.

Is n8n open source?

Not in the OSI sense. n8n's main codebase is licensed under the Sustainable Use License, which allows use or modification for your own internal business purposes or for non-commercial or personal use, and distribution only free of charge for non-commercial purposes, according to the n8n LICENSE file. Files with .ee in their name or directory are not covered by that license and require a valid n8n Enterprise License. Have counsel review the license against how you plan to host, modify and distribute workflows and custom nodes before you commit.

How do SSO and environments work on each n8n plan?

SSO and LDAP, environments with Git, and log streaming are included in the Business and Enterprise plans, according to n8n's pricing page, and are not part of the free Community edition. SAML single sign-on is available on those paid plans, with setup guides for Okta Workforce Identity and Azure AD in n8n's documentation. Confirm your identity provider is covered by those guides, and confirm which environment promotion workflow your change process needs before you pick a plan. Ask the vendor to confirm current plan contents, since pricing pages change.

What happens to our on-prem connections when we move to n8n?

Workato's on-prem agent makes only outbound connections over a TLS WebSocket tunnel, so it needs no inbound firewall ports, according to Workato's documentation. n8n does not use that agent. Instead, n8n runs inside your network, so each connection to an internal system is made directly from your n8n instances or workers. You must recreate each connection and its credentials in n8n, and confirm that firewall rules, service accounts and the database and Redis hosts allow the traffic. Test every on-prem path before cutover, since the agent's network model does not carry over automatically.

What should we export from Workato before we start?

Export your recipes using Workato's recipe lifecycle management packages, which serve as the inventory of recipes, dependencies and, where applicable, lookup table data. Use the package to list every recipe, its triggers, connectors and on-prem connections, and to mark which ones are still in use. Treat that inventory as the specification for the rebuild and for test cases, and ask your team or partner to confirm the list before estimating cost or duration.

How DeployOpen scopes and runs a Workato to n8n migration

DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For a Workato to n8n migration, we start from a written scope, rebuild recipes and on-prem connections in your environment, and hand over documentation your team can run without us.

How we scope

  • We inventory Workato recipes from the lifecycle management exports your team provides, with the privilege needed to produce them confirmed first.
  • The written scope lists which recipes, connectors, lookup tables and on-prem connections are in and out of the migration.
  • Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts, and no price is published in advance.

How we build

  • We rebuild selected recipes as n8n workflows in your own environment, mapping each Workato connector to an n8n node or custom integration.
  • We set up SSO, environments and credential handling, and confirm which n8n edition and license your scope requires before deployment.
  • We test each rebuilt workflow against the Workato original using agreed inputs, outputs and failure cases, and record the results.

How we hand over

  • You receive documentation covering architecture, workflow inventory, connection setup, encryption key handling and the runbook for operations.
  • We walk your integration and security teams through the deployed system and the rebuilt workflows so they can maintain them.
  • Each handover includes a list of open items, such as recipes deliberately retired or workflows that still need a decision from your owners.

How we support

  • Ongoing support, upgrades and continuous testing are available as a retainer after the handover, scoped separately from the migration.
  • Retainers can cover n8n version upgrades, backups and periodic testing of workflows that move business-critical data.
  • Ask us to confirm in writing what support, response expectations and service levels a retainer includes before you sign.

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.