n8n migration from Zapier or Make

What a migration to self-hosted n8n involves

Teams usually move from Zapier, Make or n8n Cloud for a small set of reasons: task or execution costs that grow with volume, a need to keep data in a specific region or network, custom code that the hosted builders cannot run comfortably, or a wish to run n8n on infrastructure you control instead of n8n Cloud. Each trigger changes what you are paying for and where workflow data lives, so write those reasons down before you start. They also tell you which workflows matter most. The work is a rebuild and verification exercise, not an export and import. Zapier and Make zaps and scenarios do not transfer as runnable n8n workflows, and n8n Cloud workflows move only as JSON that still needs its triggers, credentials and environment settings recreated. Each workflow needs its trigger re-pointed, every credential re-entered under your own encryption key, and its side effects (emails, tickets, record writes, payments) tested against real systems.

Inventory first. List every automation with its trigger type, the apps it touches, its owner, its run frequency and whether it writes to a system of record. Mark which ones send messages or change data, because those carry the most risk during a switch. Most teams do the migration in-house when the inventory is small, the workflows are simple and someone already knows n8n well. A partner is more likely to help when there are many workflows, several side-effecting ones, or no one has operated n8n before. Confirm this against your own count and skills, not a general rule.

Plan the cutover to avoid duplicate runs. Webhooks, polling triggers and schedules can all fire from both the old and new platform during overlap. For each workflow, decide when the old trigger is disabled, confirm that the new one is active, and check that no event is processed twice. Illustrative example: a lead-capture webhook still pointed at Zapier while the same form posts to n8n can create two CRM records. Agree on a cutover order and a rollback step for each workflow before the first switch.

What the migration work includes

The migration moves each automation from Zapier, Make or n8n Cloud into self-hosted n8n and retires the old copy only after the new one has been verified. The work below is typical; the exact scope is agreed in writing before work starts.

Workflow inventory and classification

Every Zap, Make scenario or cloud workflow is listed with its trigger, actions, owner, schedule, connected apps and run volume. Each one is then classified by business criticality and rebuild effort, so the team knows which automations need side-effect testing and which can move with lighter checks. Ask for the inventory to be reviewed by the teams that own each automation.

Rebuilding automations as n8n workflows

Each automation is rebuilt as an n8n workflow rather than copied step by step, because Zapier and Make use different data mapping, error handling and branching models. Logic that cannot be expressed with built-in nodes may need a Code node or a sub-workflow. Confirm which steps depend on platform-specific behavior, such as filters, formatter steps or scenario-level retries.

Recreating triggers and webhook endpoints

Polling triggers, webhooks and scheduled starts are recreated on the self-hosted instance, and every webhook URL that a third-party system calls is recorded with its new address. Webhook endpoints must be reachable from the sources that call them, so network paths, TLS and reverse proxy settings are checked as part of this work. Confirm who can update the URLs in each source system.

Re-entering and securing credentials

Credentials are not exported from the old platforms, so each connection is re-entered in n8n's encrypted credential store and mapped to a named owner and purpose. The encryption key is recorded and protected from the start, because losing it makes stored credentials unrecoverable. Ask how service accounts are created and how access to shared credentials will be restricted.

Side-effect testing against non-production systems

Rebuilt workflows are run against sandboxes or test accounts so that emails, invoices, tickets, CRM updates and payments are not triggered for real customers. Each test records the expected side effects and compares them with the actual results. Confirm that non-production systems exist for every connected application before testing starts.

Parallel running and duplicate-run prevention

During parallel running, the old and new automations process the same inputs while only one side is allowed to write to live systems. This prevents duplicate records, double notifications and repeated charges. Agree the length of the parallel period and the comparison method in advance, since the risk of duplicate runs is highest at this stage.

Cutover and decommissioning of old automations

Cutover switches triggers and webhook sources to n8n in a planned order, with a documented rollback path for each automation. Once results match, the old Zaps, scenarios or cloud workflows are disabled and then deleted after a retention period. Confirm who approves each switch and who monitors executions afterward.

Deliverables at handover

The migration register records every automation, its status and its owner. Rebuilt and tested workflows, a cutover runbook, a credential map that lists which credential serves which workflow, and handover notes for the team that will operate the instance are delivered at the end. Ask for these deliverables to be named in the written scope so acceptance is clear.

What drives migration cost and duration

The table lists the factors that change how much work a Zapier or Make to n8n move takes, why each one matters and how to keep it under control before you request a quote.

Driver	Why it matters	How to keep it down
Workflow count and complexity	Each branch, loop, error path and sub-workflow must be rebuilt and tested, so nested logic usually costs more than linear zaps or scenarios.	Inventory every workflow, tag each as simple, branched or nested, and retire unused ones before migration starts.
Number and type of triggers	Webhooks need stable URLs and signature checks, polling triggers need new intervals and state, and schedules must be rebuilt without duplicate runs during cutover.	Group triggers by type, record current endpoints, and plan a parallel-run window per trigger class.
Credentials and third-party accounts to reconnect	Every app connection must be recreated in n8n, and some accounts need owner approval, new scopes or fresh API keys.	List every connected account with its owner and required permissions, and ask the vendor to confirm which OAuth scopes the n8n node needs.
Platform-specific logic without a direct n8n equivalent	Zapier Paths, Make routers, built-in formatters and some filter functions may need custom Code node logic, which adds design and review time.	Map each platform function to an n8n node during inventory and flag gaps early so they are priced as separate build items.
Parallel execution volume	High concurrency changes how workflows are sized and tested, and may require queue mode with workers, which adds infrastructure and tuning work.	Pull execution history from the current platform and ask for peak volumes per workflow class in the quote.
Queue mode and environment requirements	Queue mode needs Redis, PostgreSQL and a shared encryption key across workers, and separate development, test and production environments add build and promotion steps.	Decide early whether queue mode is needed, and confirm whether Git-based environments require a Business or Enterprise license.
Data and PII handling	Workflows that move personal data need data mapping, retention settings for execution data, masking in logs and sometimes new approvals before testing with real records.	Classify data per workflow, use test data where possible and document which systems each workflow touches.
Compliance evidence requirements	Assessors may ask for change records, access reviews, test results and proof of credential handling, which adds documentation work beyond the rebuild itself.	Agree the evidence list before build starts so test records and change logs are captured as work proceeds.

Migration phases and what each produces

The sequence moves automations off Zapier, Make or n8n Cloud in controlled waves, with a written output at every phase so each switch-over is verifiable and reversible.

Inventory every workflow and its dependencies
Your team and ours list each Zap, Make scenario and cloud workflow with its trigger, actions, schedule, owner, volume and the systems it touches. The output is a migration register that classifies each item by business risk and by whether it can be rebuilt as-is, must be redesigned, or should be retired. Done when every item has an owner and a disposition.
Decide the target architecture and n8n edition
We document the hosting model, PostgreSQL and Redis needs, whether queue mode is required, the encryption key handling, and which features need a paid license such as SSO, Git environments or multi-main high availability. The output is a target architecture note and an edition decision record. Done when your security and platform leads have signed off on both.
Run a pilot on low-risk workflows
We rebuild a small set of internal, low-impact workflows in the new environment and run them alongside the originals to confirm node mapping, error handling and notification behavior. The output is a pilot report listing defects, workarounds and template patterns for later waves. Done when the pilot findings are reviewed and the rebuild approach is confirmed or changed.
Rebuild in waves with credential mapping
Workflows move in agreed waves grouped by system and owner. Each connection is recreated as an n8n credential under a documented ownership model, and the credential map records the source account, target credential, scope and rotation owner. Done when each wave has a completed credential map and every rebuilt workflow is peer reviewed.
Test side effects with dry runs and test data
Before any live switch, each rebuilt workflow runs against sandboxes or test data so that emails, tickets, invoices, database writes and webhooks to external systems are checked for duplicates and wrong values. The output is a test evidence pack per workflow with inputs, expected effects and observed results. Done when the owner of each affected system signs off on the side effects.
Run in parallel with duplicate-run controls
Old and new automations run side by side for an agreed period, with the new copies either disabled for live triggers or guarded by idempotency keys, deduplication checks and distinct sender identities. The output is a parallel-run log that compares executions and flags any double action. Done when the log shows no unexplained duplicates for the agreed observation window.
Cut over, decommission and hand over
We execute the cutover runbook wave by wave, disable the source automations, revoke retired connections and archive exported definitions. Hypercare then covers monitoring, fixes and runbook updates for the agreed period. The outputs are the cutover runbook, a decommissioning record and a handover pack. Done when the source platforms are disabled, the handover is accepted, and the hypercare exit criteria are met.

What teams keep in-house and what they outsource

This table lists each migration work part with its usual owner and the skills it needs, so you can see where your own team can carry the work and where a partner may help.

Work part	Usual owner	Skills required
Business owners validating outcomes	In-house (process owners)	Knowledge of what each automation must do for the business and who relies on its output
Workflow inventory and discovery	Often outsourced, with in-house review	Auditing Zapier or Make accounts, mapping triggers, actions, schedules and dependencies, and flagging unsupported steps
Rebuilding workflows in n8n	In-house if n8n skills are strong, otherwise shared	Visual canvas design, plus Code node work in JavaScript or Python for logic the built-in nodes do not cover
Credential and secret handling	Shared: in-house owns access, partner may set up vaults	Reissuing API keys, scoping OAuth connections, and managing the n8n encryption key safely
Infrastructure, PostgreSQL and Redis (if queue mode)	Often outsourced for first build, then in-house	Linux and container operations, database administration, and Redis setup for queue mode
Webhook and DNS cutover	Often outsourced, coordinated with in-house owners	Planning endpoint changes, updating source apps, DNS records and a rollback path
Side-effect testing	Shared: in-house checks outcomes, partner designs tests	Test data design, sandbox accounts, and confirming emails, invoices and CRM writes happen once
Post-cutover monitoring	In-house once handed over	Execution monitoring, alerting on failed runs, and log review after cutover

What goes wrong in n8n migrations and how to prevent it

Most failed cutovers from Zapier or Make are not tool failures. They come from two platforms running at once, credentials and webhooks that were never fully moved, and behavior that quietly changed. Each risk below has a prevention step to plan before the first workflow is rebuilt.

Duplicate runs during parallel running

When the old Zap or Make scenario and the new n8n workflow both listen to the same trigger, one event creates two records, two emails or two tickets. Freeze the old trigger before the n8n trigger is activated, and record the freeze date and owner in the migration inventory so nobody re-enables the original automation by mistake.

Webhooks still pointing at the old platform

Forms, SaaS apps and partner systems often hold the Zapier or Make webhook URL in their own settings, so events keep flowing to the old platform after n8n is live. Inventory every inbound endpoint, switch them in stages with a planned window, and confirm in the n8n execution log that each source now arrives at the self-hosted webhook URL.

Credentials re-created with wrong scopes

Re-entering a connection in n8n with a personal account or a broader scope than the original can expose data the workflow never used before. Expired OAuth tokens also fail silently on schedules that run weekly. Record the scopes each automation needs, create service-owned credentials, and test each one with a read call before the workflow is activated.

Silent changes in data mapping

Zapier and Make coerce types, trim whitespace, handle empty fields and format dates in their own ways, and n8n does not reproduce those defaults automatically. A date that arrived as text or a blank field that became an empty string can reach the CRM in a different form. Compare sample outputs field by field against the original runs, including edge cases such as empty and multi-value fields.

Rate limits during parallel running

Running both platforms against the same SaaS API doubles the request volume, and bursts from a backfill or a retry loop can trigger provider throttling for both. Check each API's documented limits before parallel running starts, batch or split large backfills, and watch for HTTP 429 responses in the n8n execution log during the overlap period.

Error handling the old platform provided

Zapier and Make surface failed steps through their own history and notification features, and teams often rely on those without writing it down. n8n workflows need an explicit error workflow, retry settings on flaky nodes and an alert destination. List which failure notifications the team received before migration and confirm each has an equivalent in n8n.

Side effects triggered during testing

Testing a rebuilt workflow against live systems can send customer emails, create invoices or write contacts to the CRM. Use test sandboxes, separate test accounts and disabled send nodes or pinned data for development, and mark each side-effecting node in the inventory so reviewers know which steps must be stubbed before a test run.

How the migration differs by starting point

Zapier zaps rarely move as a file, so most teams rebuild them as n8n workflows and use the existing zap as the specification. Confirm with your own Zapier account which zap details you can export and which you must record by hand.

Trigger handling: Each trigger is configured again in n8n. Webhook URLs change, so every sending system must be repointed and tested.
Credential re-entry: Every app connection is recreated in n8n using the target service's current authentication. Plan for each connection owner to approve reconnection.
Execution model: n8n counts one execution per workflow run, whatever the number of steps. Compare volume in runs, and confirm your Zapier task and billing details in your own account before comparing.
Data location: Zapier run history stays in Zapier. Execution data in n8n is stored in your PostgreSQL database, so set a pruning policy before go-live.

What your team needs to provide

The inventory your team provides determines most of the quote. A migration is priced by how many workflows exist, how many touch live systems, and how many credentials and owners must be confirmed before anything is rebuilt. Incomplete inputs push discovery into the build phase, where it costs more and delays cutover. Start by confirming the inputs below, and ask the implementation partner to state in writing which of them it needs before the fixed-scope quote is issued.

Start with access and exports. Provide admin access to the source platforms, whether Zapier, Make or n8n Cloud, so the current workflow list, run history and connected accounts can be read. Where the platform allows it, export workflow definitions as well. Some platforms export the structure but not the credentials, so confirm with the vendor what each export contains. Also provide a named owner for every automation, since owners decide whether a workflow is retired, rebuilt or left alone.

Then decide on the target. Confirm the n8n edition and hosting location, because the license terms and the features you need (such as SSO or Git environments) determine what can be built. Choose how secrets will be managed, including where encryption keys live and who may read them. Provide access to target systems in both test and production, plus test accounts and sample data that can receive side effects such as emails, CRM updates or invoices without touching real customers. Without these, the team cannot verify that rebuilt workflows behave the same way.

Finally, provide the cutover rules. Agree change windows in which each workflow can be switched, and name a business approver for each critical workflow who can accept the test results and the switch. Duplicate runs happen when a trigger is live in both platforms at once, so the approver and the change window must be decided together. Ask the partner which decisions it expects you to make and by when, and confirm which of these inputs are included in the quote and which remain your team's responsibility.

Frequently asked questions about migrating to n8n

What drives the cost of migrating workflows to self-hosted n8n?

The cost depends mostly on how many workflows you have, how complex they are, and how many credentials and triggers must be rebuilt and tested. Main cost components:

Discovery and inventory: listing every zap or scenario, its owner, triggers, and side effects.
Rebuilding: recreating logic in n8n, especially branching, loops, custom code, and error handling.
Testing: verifying outputs and external side effects such as emails, invoices, and CRM writes.
Hosting and cutover: the infrastructure you run and the switchover window.

Ask for a fixed-scope quote that lists each workflow group and what is included. Hosting and license fees recur, while migration work is typically one-time.

How long does a migration from Zapier or Make take?

Duration follows the phases in your written scope, not a generic figure, because it depends on workflow count, complexity, and how many systems must be reconnected. The scope should name discovery, build, testing, and cutover as separate phases with agreed timelines. Before signing, confirm which workflows are in the first wave, who approves each test result, and what must be true before the source platform is switched off. Ask for those dates in the written scope.

Can Zapier or Make workflows be exported and imported into n8n automatically?

It depends on the source platform and the workflow features used, so confirm this during discovery. Some trigger and action definitions may map cleanly, while app-specific steps, filters, formatters, and proprietary functions usually need manual rebuilding. Discovery should produce a list of each workflow with a rating for automatic transfer, partial transfer, or full rebuild. Do not assume an import will produce working automations without review.

What does our team need to provide for a migration?

The work moves faster when your team supplies access and decisions early. Typically required from your side:

Export or read access to the source workflows and their run history.
Named business owners who can approve test results for each workflow.
Accounts or service credentials for every connected application, and a secrets storage decision.
Target hosting, network access, and a database and Redis plan that matches your environment.
A cutover window agreed with the teams that depend on the automations.

List these items in the scope so gaps are visible before build starts.

Can our own team migrate the workflows without a partner?

Yes, many teams do this internally, especially with a small number of simple workflows. The main questions are whether your engineers have time for inventory, rebuilding, and testing, and whether they can run the platform after go-live. A partner is most useful when workflow volume is high, when side effects are hard to test, or when staff are needed for hosting and operations. Compare your internal estimate with a fixed-scope quote before deciding.

How do we avoid duplicate runs during the switchover?

Duplicate runs happen when the old and new platforms both listen to the same trigger, such as a webhook, polling source, or schedule. Plan a switch for each workflow: deactivate the source trigger, activate the n8n trigger, and confirm one run per event. Keep a log of each cutover so you can roll back. Also check any downstream systems that deduplicate poorly, because a double write can cause invoices, emails, or records to repeat.

How DeployOpen runs n8n migrations

DeployOpen plans and carries out the move from Zapier, Make or n8n Cloud to self-hosted n8n inside infrastructure you control, with each workflow inventoried, rebuilt and tested before traffic moves. The work is delivered as a written, fixed-scope engagement with ongoing support available as a retainer.

How we scope

The written scope lists every Zapier, Make or n8n Cloud workflow to be moved, along with the ones intentionally retired.
Scope records each trigger, app connection and credential the workflows depend on, and who must re-authorize them.
Scope states which edition and license terms apply, and whether SSO, Git environments or queue mode are included.

How we build

Each workflow is rebuilt in self-hosted n8n and mapped side by side against its original logic and outputs.
Credentials are recreated in the new instance with encryption key handling agreed in advance, not copied from the source platform.
Side effects such as emails, CRM writes and invoices are tested in a staging copy, and duplicate-run safeguards are set before any cutover.

How we hand over

Handover includes a workflow register showing each migrated workflow, its owner, its trigger type and its cutover status.
Runbooks cover how to disable the old automation, verify a live run and roll back a workflow if an integration fails.
Your team receives documentation of the hosting, database backup and credential-handling setup in your own environment.

How we support

Post-go-live support covers monitoring of migrated workflows and fixes for issues traced to the migration work.
Ongoing retainers can cover n8n upgrades, which are tested against your workflows before they reach production.
Ask whether the retainer includes new workflow builds, since these are usually quoted separately from the migration.

Migrating to n8n from Zapier or Make