Migrate from Zapier to n8n: what the move involves and who does it
Most teams arrive here because a task bill keeps growing, a data residency rule rules out hosted automation, or they want their Zaps stored and versioned in their own systems. The move is a rebuild, not an import: Zapier's JSON export gives you an inventory of what each Zap does, but n8n does not read that file as a workflow, so each automation is recreated as an n8n workflow and tested against real inputs. The export is only the starting point, and it must be taken by an account owner or super admin on a Team or Enterprise plan, since the help center's import and export guide limits JSON export to those plans and delivers all-user exports by email.
Credentials and webhooks do not carry over. Every app connection must be recreated in n8n with the account and scopes it needs, and every inbound webhook URL changes, so each source system that posts to a Zap needs a new endpoint and a cutover date. Effort scales with the number of Zaps, how many steps and branches each one has, how many apps and custom HTTP calls it uses, and how much logic lives in code steps. Ask each team to list which Zaps are business critical and which are stale before anyone estimates the work, because a large share of most Zap estates is often unused. Confirm with n8n which edition and license key you will run, since Community, Business and Enterprise differ in features such as SSO, Git environments and log streaming.
Internal platform or integration engineers usually own the rebuild, because they know the systems behind each Zap and can own the n8n hosting, encryption key handling and backups afterward. Some organizations bring in an outside implementation partner for the inventory, the rebuild of high-risk flows and the hardening, with the scope and deliverables fixed in writing first. The main risks are silent failures during cutover, where a Zap stops firing and nobody notices, and credentials or webhook secrets copied insecurely during the rebuild. Run old and new flows in parallel for each critical Zap, keep a dated cutover log, and plan who is paged when a self-hosted workflow fails, because nothing in n8n will alert you by default.
Which Zapier capabilities map cleanly to n8n and which need rework
This table compares the Zapier building blocks most teams use with their n8n equivalents and marks each row as clean, needs rework or gap. Use it to scope the rebuild before you export anything, because the rework rows drive most of the effort. Confirm connector coverage for each app you depend on in the n8n catalog, since n8n advertises more than 1,500 integrations but that count does not confirm every app.
| Zapier capability | n8n equivalent | Status |
|---|---|---|
| Triggers and actions for listed apps | Built-in nodes for the same apps, confirmed in the n8n catalog | Clean for common apps; confirm each app |
| Multi-step Zaps | Workflows with chained nodes on one canvas | Clean |
| Filters | IF and Filter nodes | Clean |
| Paths | Switch node with multiple outputs | Needs rework |
| Code steps (JavaScript or Python) | Code node; library and runtime limits differ from Zapier's sandbox | Needs rework |
| Scheduled triggers | Schedule Trigger node, with timezone and cron settings to recheck | Clean |
| Webhooks | Webhook node; production URLs change and must be re-registered with senders | Needs rework |
| App connections | Credentials recreated manually; secrets are not carried over from the Zapier export | Needs rework |
| Zap version history | No direct equivalent; keep workflows in Git through n8n environments on Business or Enterprise | Gap |
| Admin export of all users' Zaps | JSON export is an inventory for rebuilding, not an importable file | Gap |
| Zapier Tables and AI features | Map separately to a database such as Baserow and to n8n AI nodes | Gap |
The migration sequence from Zap inventory to decommission
This sequence turns a list of Zaps into a tested set of self-hosted n8n workflows, then retires the Zapier versions once the rebuilt ones have proven they produce the same results. Each step closes with a written output so the migration can be reviewed and audited before the next step begins.
Build the Zap inventory from JSON exports
Start by exporting every Zap as a JSON file. Zapier's JSON import and export is available only on Team and Enterprise plans, so if your account is on another plan, the export has to be done on a plan that supports it. Account owners and super admins can instead request an export of all Zaps from every user in the account from Settings, under Security and data. Zapier delivers that archive by email, so confirm who receives it and where it is stored. Record each Zap's owner, trigger app, action apps, whether it is on or off, and the business process it supports. The output is a spreadsheet or table with one row per Zap, plus the raw JSON files kept under change control. Treat these files as an inventory for rebuilding, not as something n8n will import.
Pilot a few representative Zaps in n8n
Choose a small set of Zaps that cover your common patterns: a webhook trigger, a scheduled trigger, a multi-step action chain, a filter, and one that calls an internal API. Stand up a self-hosted n8n instance, starting with the free Community edition if the pilot does not need SSO, environments or log streaming. Rebuild each chosen Zap as an n8n workflow, recreate its credentials in n8n's credential store, and map each step's inputs by hand from the exported JSON. Where a Zapier app has no matching node, decide whether to use an HTTP Request node, a code step or a different tool. The output is a short pilot report listing each rebuilt workflow, each credential created, every gap found, and the owner who signed off on the design.
Run old and new side by side with idempotency checks
Point test copies of the source events at both the Zap and the rebuilt n8n workflow, or let both run on real events while the n8n outputs go to a non-production destination. Compare the results field by field for each run. Because a retry or duplicate event can cause a write to happen twice, check each workflow for idempotency: confirm that a repeated trigger event does not create duplicate records, emails or tickets, for example by using a stable event ID as a key in the destination. Track failed executions and compare how each platform reports them. The output is a parallel-run log with matched and mismatched results, the idempotency test results, and a written decision from the workflow owner that each rebuilt workflow is ready to take live traffic.
Cut over webhooks and activate rebuilt workflows
Schedule the cutover with the owners of each upstream system that calls a Zapier webhook URL. Repoint those callers to the n8n webhook URL on your own domain, and confirm that the new endpoint accepts the same payload and authentication method. Activate each rebuilt workflow in n8n and then check every app connection in the workflow, because credentials do not move with the JSON and must be recreated and tested in the new environment. Confirm that the n8n encryption key is handled correctly for your deployment. If you run queue mode, the main instance's encryption key must also be shared with every worker and webhook processor so they can read stored credentials. The output is a cutover record listing the repointed webhooks, the activated workflows, the connection test results and the time each change went live.
Disable Zaps and retain logs for decommission
After the cutover has run without unexpected behavior for the period your change policy requires, turn off each replaced Zap in Zapier. Do not delete them immediately. Keep the exported JSON, the parallel-run logs, the cutover record and the Zapier run history that your retention rules call for, and store them in your own records system. Confirm the Zapier subscription end date with your account owner, and confirm what Zapier retains after cancellation, since that is a question for Zapier and your contract. Once the retention window closes and the owners approve, cancel the plan or downgrade it. The output is a decommission record that lists every Zap disabled, where the archived evidence is kept, and who approved removal of the account.
How the move differs for small teams, large accounts and regulated environments
A small team with a handful of Zaps on a single plan usually has the simplest inventory, but the export path may be the first obstacle. Zapier's JSON export and import are available only on Team and Enterprise plans, so a team on a Free or Professional account may need to upgrade before it can take an inventory file at all, or rebuild every Zap by hand from the editor. Because only a few workflows are involved, the rebuild is often done by one or two people who also own the connections.
- Export path: Confirm the plan level first. Free and Professional accounts cannot use the JSON export, so the inventory may come from reviewing each Zap in the editor.
- Connection ownership: Identify which personal accounts authenticate each app. Recreate those credentials in n8n under a service account where the vendor allows it.
- Webhook URLs: Any Zap triggered by a webhook will receive a new endpoint in n8n. Plan the cutover so the sending system is updated before the old Zap is turned off.
- Testing: Run each rebuilt workflow against test data and compare outputs with the live Zap for a set period before switching triggers.
- Licensing: A small internal team fits the Sustainable Use License's internal business use, but confirm the use case with n8n before any external or commercial distribution.
Before cutover, confirm which Zaps are business critical, who receives their alerts and how a rollback would run.
A large account with many users and admin exports has a different problem: the inventory is big, owned by many people and includes Zaps nobody has reviewed for a long time. Account owners and super admins can export all Zap workflows from all users, but the file arrives by email rather than as an on-screen download, so the export needs a named owner and a secure place to store it. The JSON file is an inventory for rebuilding, not a file that another tool imports, so each workflow still has to be recreated and checked.
- Inventory triage: Sort exported workflows by owner, trigger type, connected apps and last use. Retire unused Zaps instead of rebuilding them.
- Credential sprawl: Many Zaps may depend on connections owned by departed or shared users. Map each connection to a current owner before rebuilding.
- Access and environments: Use n8n's Business or Enterprise plan for SSO, environments with Git and log streaming. Confirm these features against the current n8n pricing page before budgeting.
- Staged cutover: Migrate by department or workflow group, with a parallel run and a named owner for each group.
- Scale planning: For high volume, ask about queue mode, which uses Redis and PostgreSQL, and confirm whether the chosen plan covers the required deployment model.
Ask for a written inventory of owners, connections and triggers before estimating the rebuild effort.
A regulated or air-gapped environment must keep credentials, workflow data and run logs inside its own network. The migration is less about the Zap logic and more about where secrets live, who can reach the n8n instance and how the encryption key is protected. In queue mode, the main instance's encryption key must be shared with every worker and webhook processor so they can read stored credentials, which makes that key a high-value secret to manage and rotate.
- Credential custody: Recreate every connection inside the controlled environment and avoid copying secrets through email or chat. Store the encryption key in a managed secrets store with restricted access.
- Network design: Confirm which systems n8n must reach, and whether inbound webhooks need to be exposed. Where the source systems are internal, ask whether an on-prem connector or agent approach suits your architecture.
- Licensing for internal use: The Sustainable Use License allows internal business use, but files with .ee in their name require an n8n Enterprise License. Confirm with n8n which features your deployment depends on.
- Testing and change control: Document each rebuilt workflow, test it in a non-production environment and record approvals before cutover.
- Evidence: Auditors will ask how credentials are stored and who can read them. DeployOpen can prepare the controls and evidence, but independent auditors and certification bodies issue the assessment.
Confirm your data classification and approval path with your compliance team before any credential is recreated.
Does n8n's Sustainable Use License fit how you will use it?
n8n is source-available, not OSI open source. Its main codebase is under the Sustainable Use License, so before you migrate Zaps into it, confirm that your way of running it is one the license permits. The license allows use or modification for your own internal business purposes, or for non-commercial or personal use. Distribution is allowed only free of charge and only for non-commercial purposes. For most organizations that run n8n inside their own network to automate their own internal systems and SaaS tools, this is the typical case and it sits within the permitted internal business use.
Several parts of the repository fall outside that grant. Files with .ee in their name or directory are not covered by the Sustainable Use License and require a valid n8n Enterprise License. This matters during the rebuild because features you pick up from those paths are governed by a different contract than the core. Separately, offering n8n to your own customers as a managed service, or reselling or redistributing it, needs its own review and is not the same as internal automation. Read the current n8n license text against your planned deployment, and note which operational choices, such as hosting it for a subsidiary or a client, change the answer.
Ask your counsel to confirm the fit in writing before production cutover, and record the decision alongside your architecture notes. Useful questions include whether your affiliates or contractors may use the instance, whether any workflow will be offered to external parties, and whether you will rely on any Enterprise-only feature. The license is also a reason to keep the Zapier JSON export and your rebuild inventory, since they document what you built regardless of the tool. This is a planning check, not legal advice, and the final reading belongs to your legal team.
What exports, what gets recreated and what you rebuild by hand
Zapier gives you a JSON file of your Zaps, but that file is an inventory for rebuilding, not something n8n imports. Each part of a Zap lands in a different place: structure is rebuilt, credentials are re-entered, history stays behind, and custom code needs review before it runs again.
Zap JSON exports
The JSON export lists each Zap's trigger, action steps and field mappings, so you can count and classify what you have before you rebuild anything. Only Team and Enterprise plans can import and export Zap JSON, and account owners or super admins can export every user's Zaps in one batch. Treat the file as a spec: n8n will not read it, so each Zap becomes a new workflow you build and test on a canvas. Confirm the export is complete for every user before you start.
App connections and credentials
Zapier does not hand over stored app logins, so every connection is created again in n8n under its own credential record. In queue mode, the main instance's encryption key must also be shared with every worker and webhook processor, or they cannot read the stored credentials. Store that key in your secrets manager, record who holds it, and plan how you rotate it. Re-authorize each account with a service identity where the vendor allows it, so the workflow does not depend on one employee's login.
Webhook URLs
Catch-hook and webhook triggers in Zapier have URLs that belong to Zapier, so n8n creates new endpoints on your domain. Every sender that posts to an old Zapier URL, including forms, SaaS webhooks and partner systems, must be updated to the new address. Run old and new endpoints side by side for a short overlap, and log which senders still hit the Zapier URL. Confirm that your reverse proxy and TLS certificates serve the n8n webhook path before you switch any sender.
Zap history and run logs
Run history, task logs and error records stay in Zapier and are not part of the JSON export. If auditors or incident responders may need past runs, export or archive the relevant records from Zapier before you turn Zaps off, and keep them in your own retention system. n8n's execution history starts when your workflows first run on your servers, so its logs cover only the new period. Set execution data retention in n8n deliberately, because it holds personal data from every run.
Zapier Tables data
Lookup tables, queues and other data stored in Zapier Tables do not come across in the Zap export. Move each table separately into a self-hosted database, then point the rebuilt n8n workflows at the new location. Count the tables and the records in each before you start, and check that every workflow that reads or writes a table has a matching destination. Test read and write paths with copies of the data before cutover, so a lookup does not silently return empty results.
Custom code steps
Code steps in Zaps are written in Zapier's own runtime, so they must be reviewed line by line and ported to n8n Code nodes. Check every external call, every secret read and every library the code assumes is present. Remove any code that copies data to a third party you have not approved, and confirm that n8n's Code node can run what remains in your chosen Node.js or Python setup. Test each ported step against sample inputs and record the expected outputs as your acceptance criteria.
Running Zapier and n8n in parallel without double-firing
The main risk in a parallel run is that the same event reaches both Zapier and n8n, so a single new lead, invoice or ticket creates two records, sends two emails or charges twice. Prevent this by deciding, for each workflow, which platform owns the trigger. Turn off the Zap or pause its trigger before you switch on the matching n8n workflow, and do not leave both listening to the same app event. Where a source system can send webhooks to both tools, point the webhook at one endpoint only and confirm the old endpoint no longer receives traffic. Record the owner of each trigger in your migration inventory so nobody re-enables a Zap by mistake.
Test before any live action runs. Point rebuilt n8n workflows at sandbox or test accounts for every connected app, and use test data that is clearly marked so you can recognize it in downstream systems. Compare outputs side by side: run the same sample input through the original Zap and the n8n version, then check the records created, field mappings, date and currency handling and the run history in each tool. Remember that n8n counts an execution as one run of a whole workflow, which makes run counts easier to compare, but it does not confirm that the actions match. Confirm with each app's vendor how its sandbox works and whether it allows separate test credentials for the same user.
Cut over one workflow group at a time, starting with low-impact workflows that have clear owners and can be rolled back in minutes. Keep the Zapier account on a plan that still lets you run and edit Zaps until the last group is verified, and retain the JSON export as the reference for each rebuilt flow. After any import, Zapier requires you to turn Zaps on and check app connections, and the same discipline applies to rebuilt n8n workflows: activate them deliberately, re-authenticate every credential in your own instance, confirm webhook URLs and test each trigger. Only then retire the old Zap so it cannot fire again.
What drives migration cost and duration, and how to keep each down
This table lists each cost component of moving Zaps to self-hosted n8n, who is paid for it, whether it is one-time or recurring, and what pushes it up or down. Use it to shape a written scope and to check that a quote covers every line.
| Cost component | One-time or recurring | What drives it up | How to keep it down |
|---|---|---|---|
| Zap inventory and complexity | One-time | Large numbers of Zaps, multi-step paths, filters, formatter steps and branching logic | Export the full JSON inventory first, retire unused Zaps and rebuild only live workflows |
| Distinct app connections | One-time | Each separate app needs a new credential, scope review and test call in n8n | Group Zaps by shared apps, reuse one credential per app and confirm which connections still have owners |
| Custom code steps | One-time | Zapier code steps that need rewriting in n8n's JavaScript or Python nodes, or logic that depends on Zapier-specific behavior | Move only logic that cannot be a native node, and keep code steps small and tested |
| Webhook senders to update | One-time | Every external system that posts to a Zapier webhook URL must be changed to the new n8n webhook URL, often owned by other teams | Build a list of senders from each Zap's trigger, schedule changes with those owners and keep old endpoints live until cutover |
| Testing and parallel run | One-time | Duplicate runs in Zapier and n8n, reconciliation of outputs, and sign-off from workflow owners | Set acceptance checks per Zap in advance and run both platforms side by side only for workflows with business impact |
| n8n hosting infrastructure | Recurring | Compute, database, backups, storage and any queue mode workers that you size and pay for | Start with a single instance sized to actual execution volume, and confirm the hosting cost model with your cloud or data center team |
| n8n license tier | Recurring | SSO through SAML, environments with Git, and log streaming require the Business or Enterprise plan per n8n's pricing page. Those plans are listed at 667 euros per month billed annually for Business, with Enterprise at custom pricing | Use the free Community edition if those features are not required, and confirm current prices directly with n8n because the pricing page may change |
| Internal license fit | One-time | The Sustainable Use License limits use to internal business or non-commercial purposes, so a client-facing or resold service may need a different arrangement | Have legal review the intended use before the build starts and record the decision |
| Ongoing maintenance and upgrades | Recurring | Node updates, n8n version upgrades, credential rotation, security patching and on-call coverage for failed runs | Set a patch and upgrade routine, monitor failed executions and document ownership for each workflow |
| Services and support | One-time or recurring | Fixed-scope rebuild work, retainer support, or internal staff time that is not budgeted | Ask for a written scope with deliverables, named tasks per Zap, and whether support is included after cutover |
Questions buyers ask before moving from Zapier to n8n
How much effort does a Zapier to n8n migration take?
Effort depends mainly on how many Zaps you run, how many steps each one has, and how many distinct apps and credentials they use. Zapier's JSON export gives you a complete inventory of Zap workflows, but it is an inventory for rebuilding, not a file n8n imports. Each Zap is recreated as an n8n workflow, so simple two-step Zaps move quickly while multi-branch Zaps with filters, formatting and custom code take longer to test. Ask any partner to size the work from a full export and a list of which Zaps are business critical.
How long does the migration run?
No fixed duration applies, because the length of the project is set by the drivers above and by how many Zaps must run in parallel during cutover. Plan for a period where Zapier and n8n both run, so you can compare outputs and switch triggers over one workflow at a time. Teams that move in batches by business owner usually finish sooner than teams that try to cut everything over at once. Confirm the schedule against a written scope before work starts.
Can our own team migrate from Zapier to n8n without outside help?
Yes, a team with workflow and API experience can rebuild Zaps in-house, and the n8n Community edition is free to self-host under the Sustainable Use License for internal business use. The work that usually needs more time is hosting setup, credential management, testing failure paths and operating the instance after go-live. If those skills are thin in your team, a fixed-scope engagement can cover planning, implementation, hardening and documentation while your staff keep ownership.
Can Zapier Zap exports be imported directly into n8n?
No. Zapier supports importing and exporting Zap workflows only as JSON files, and only on Team and Enterprise plans, so Free and Professional accounts cannot use the feature. The exported file works as an inventory of triggers, actions and mapped fields that you use to rebuild each workflow in n8n. Account owners and super admins can also export all Zap workflows from all users, which Zapier sends by email from Settings, Security and data. After any import on the Zapier side, Zaps must be turned on and app connections checked.
What does the Sustainable Use License allow for internal use?
The Sustainable Use License permits you to use and modify n8n for your own internal business purposes, and for non-commercial or personal use. Running n8n to automate your company's own processes fits that grant, but the license is source-available, not OSI open source, so it is not the same as an MIT or Apache license. Distribution is limited to free, non-commercial use, and files with .ee in their name require a valid n8n Enterprise License. Have your legal team review the LICENSE.md file against your intended use, especially if you plan to offer automation services to customers.
Does n8n SSO require a paid edition?
Yes. According to n8n's pricing page, SSO and LDAP are included only in the Business and Enterprise plans. n8n SAML single sign-on is available on those plans, with setup guides for Okta Workforce Identity and Azure AD. The Community edition runs without a license key and does not include these features, so plan identity integration and access control for your environment before choosing an edition. Confirm current plan contents on the pricing page, since editions can change.
How are credentials and webhooks handled after the move?
Credentials are not carried over from Zapier, so each app connection must be recreated in n8n with fresh authorization, and webhook URLs change, so every external system that calls a Zap must be pointed at the new n8n endpoint. In queue mode, the main instance's encryption key must be shared with all worker and webhook processor nodes so they can read stored credentials. Store that key securely, back up the database, and test each webhook end to end before switching the source system over.
What usually goes wrong in a Zapier to n8n move and how to prevent it
Most failed Zapier to n8n moves break in the same few places: work runs twice, credentials go missing, old webhooks keep firing, and workers cannot decrypt stored secrets. Each risk below has one prevention step to put in your migration plan before the first workflow goes live.
Duplicate actions during parallel runs
While a Zap and its rebuilt n8n workflow both listen to the same trigger, one event can create two invoices, two tickets or two emails. Before cutover, assign each trigger to exactly one platform and turn off the Zap, not just the n8n copy. Then compare run logs from both systems for a set period to confirm each event was handled once.
Lost credentials and stale connections
Zapier JSON exports carry the workflow structure but not the app connections, so every n8n credential has to be created again by hand. After import, Zapier also expects connections to be checked, and the same applies in n8n. Keep an inventory of each app account, its owner and its scopes, and test each credential with a real read and write before turning the workflow on.
Webhook senders still pointing at Zapier
Forms, payment tools and internal scripts often send webhooks to a Zapier catch URL that nobody remembers. Once the Zap is off, those events fail silently or are dropped. Search your sender configurations and API integrations for every Zapier hook URL, repoint them to the n8n webhook endpoint, and send a test event from each sender.
Missing encryption key sharing in queue mode
In n8n queue mode, the main instance hands executions to workers through Redis and workers read credentials from PostgreSQL. Each worker and webhook processor needs the main instance's encryption key, or it cannot decrypt stored credentials and runs fail. Set the same key on every process before scaling out, and confirm a worker can execute a credential-backed workflow before you rely on it.
Underestimated custom code
Zapier's code steps and formatter logic often hide assumptions about input shape, retries and timeouts that do not carry over. n8n can run custom JavaScript or Python, which means your team now owns that code, its dependencies and its errors. Inventory every code step during the JSON review, write tests against sample payloads, and assign an owner for each script.
High availability expectations
Teams often assume that running two n8n main instances gives them failover. Multi-main setup for high availability is restricted to Enterprise self-hosted deployments and is not available in the Community edition or n8n Cloud. Confirm your edition and license before design, and if you need HA on a lower tier, plan for a documented restart and recovery process instead.
Where an implementation partner adds value in this migration
An implementation partner earns its place in the parts of this migration that are easy to underestimate. The first is scoping the inventory. Zapier's JSON export, which Team and Enterprise account owners and super admins can pull for all users from Settings, Security and data, lists every Zap, but it does not tell you which Zaps are still used, who owns them, or which ones depend on a webhook URL that other systems call. Someone has to sort that list into keep, rebuild, retire and merge groups before any n8n work starts. DeployOpen plans and implements self-hosted platforms inside the client's own cloud accounts, data centers or air-gapped networks, and the migration scope, deliverables and timelines are agreed in writing before work begins, so the inventory review and the n8n deployment design can be scoped as a fixed piece of work rather than an open-ended project. Designing the n8n deployment is the second area. The choice between a single Community install, a Business license setup and queue mode with Redis and PostgreSQL workers is driven by execution volume, high availability needs and your identity requirements, and the features you need, such as SAML single sign-on or environments with Git, depend on the edition you pick. Confirm those edition boundaries against n8n's pricing page at the time you decide.
The second part of the value is credential and encryption key handling, plus webhook cutover. Zapier exports do not carry working connections, so every app credential must be recreated in n8n, and this is where security teams should set the rules first: who may create credentials, where the n8n encryption key is stored, and how that key is backed up. In queue mode the main instance's encryption key must also be shared with every worker and webhook processor so they can read stored credentials, which means a key mishandled in one place exposes the whole set. Webhook cutover needs its own runbook: each inbound Zapier webhook URL has to be mapped to the new n8n endpoint, the calling systems updated, and both paths tested in parallel before the old Zap is switched off. Finally, plan documentation for handover, covering the rebuilt workflow inventory, owners, credential locations, key custody, restore steps and the reasons for each design choice. Ask any partner for those deliverables in the written scope so the internal team can run the platform after the engagement ends.
How DeployOpen scopes, runs and supports a Zapier to n8n migration
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For a Zapier to n8n move, we start from a written scope that lists your Zap inventory, your credential and webhook dependencies and the n8n deployment you will run.
How we scope
- Inventory every Zap from the JSON export, including which accounts and teams own each one
- Record each app connection, credential type and webhook URL that must be recreated in n8n
- Confirm the n8n edition and license fit for your internal use before any build starts
How we build
- Deploy n8n in your own cloud account, data center or air-gapped network, using the hosting method your scope names
- Rebuild prioritized Zaps as n8n workflows, then test each one against the same inputs and outputs
- Configure credential storage and the encryption key handling your chosen topology requires, including queue mode workers where they apply
How we hand over
- Deliver runbooks for deployment, credential rotation, backups and workflow changes in your repository
- Provide a test record for each rebuilt workflow, showing what was checked and what was retired
- Walk your team through operating the instance so ownership of workflows sits with your staff
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover
- Apply n8n version upgrades and review release notes in a staging copy before production
- Keep security testing on the self-hosted instance and its workflows as a separate, scoped engagement
