Zapier to n8n migration: map, rebuild and switch.

Choose a process whose inputs and intended result you can explain in a few sentences. Our example accepts a website enquiry, checks its email and a permission flag, maps fields and creates a CRM record once. It holds invalid or unpermitted input for review. This is a useful starting point because each branch has a visible outcome.

Keep a working Zap when the move adds maintenance without solving a concrete problem. For the platform decision, use the n8n vs Zapier comparison. This guide covers implementation after that decision; it does not claim a percentage saving, faster production execution or a measured Zapier-versus-n8n result.

Before rebuilding, list the workflow owner, trigger type, filters, paths, delays, connections and downstream record IDs. Include polling intervals, time zones and any pending delayed actions. A workflow that appears idle may still have work scheduled for later.

Save the source definition and a readable record of its settings. Zapier documents JSON workflow export for Team and Enterprise accounts. If your plan lacks that option, document the editor steps, expressions and connections. See Zapier’s import/export documentation, checked on 6 September 2026.

Zapier and n8n use different workflow structures. Treat a Zap export as your reference, then rebuild the n8n operations and expressions. Do not assume two JSON files are interchangeable. The table below is an implementation mapping, not a claim of an automatic converter.

Our lab uses a Manual Trigger and a local HTTP input fixture so the same scenarios can be repeated. Replacing these with a production trigger is a separate integration step. The demo does not receive public website enquiries.

Write the destination contract before wiring the connector. Distinguish an event ID from a customer ID: one customer may submit several legitimate enquiries, while a repeated delivery of the same enquiry should not create another record.

The permission flag is a fixture rule. Your actual process needs its own purpose, channel and permission requirements. Hold missing information for review instead of filling it with invented values. If the next step is customer follow-up, connect this mapping to the CRM lead follow-up design before adding messages.

For each connection, record the account owner, test or production environment, required operations and renewal process. Reconnect through n8n’s credential configuration. Check OAuth scopes and redirect URLs, API base URLs and whether the source workflow depends on a shared service account.

• Use a test destination and credentials limited to the operations being migrated.
• Verify lookup and write access with an approved sample record.
• Document credential expiry, rotation and the person responsible for recovery.
• Inspect exports before sharing: remove secrets, sensitive account names and authentication headers.

The n8n export/import documentation explains that workflow exports include credential names and IDs, and HTTP nodes can contain authentication headers. An export is not proof that a connection has been transferred successfully. Our synthetic CRM requires no credentials, so the lab results do not certify production authentication.

A request can time out after the destination has committed a record. Retrying without a stable key can then create a duplicate. Our local CRM stores the event ID and returns the existing result when that event is delivered again. The n8n HTTP node passes the same ID on each attempt.

This works because the destination implements the duplicate check. Sending an Idempotency-Key header to an API that ignores it does not provide protection. In a real integration, use a supported unique key or upsert operation, or a durable event ledger that handles concurrent delivery.

The demo permits three total attempts with a one-second interval. A synthetic temporary 503 succeeds on attempt two; a permanent 503 remains failed after attempt three. Choose production intervals from the provider’s limits and error responses. Fix invalid fields or revoked credentials rather than retrying them indefinitely.

Give exhausted failures an owner and enough context to recover: event reference, last completed action and destination response. n8n’s error-handling documentation describes attaching a separate error workflow beginning with Error Trigger. The lab records failures locally; it does not send alerts or demonstrate a production error workflow.

We ran the lab on 6 September 2026 using n8n 2.19.3 and Node 26.7.0. It sends synthetic example.test records to a CRM fixture on 127.0.0.1:4398. It sends no email and writes to no external CRM.

• Download the actual exported n8n workflow.
• Download the fixture builder and scenario runner.
• Read the reproduction instructions and timestamped execution results.

Use a new empty folder and an isolated n8n user directory. The README pins the tested version and commands. The local fixture must run alongside the workflow; importing the JSON alone does not provide a CRM. The export is an n8n workflow, not an exported Zap.

The lab uses the server CLI commands available in the tested version. Current n8n documentation also describes a separate n8n CLI and preview packages for moving workflows between instances. Follow the current import/export guidance for a new deployment rather than treating a version-pinned lab command as a universal migration method.

Six scenario executions made seven CRM POST attempts and created two unique records. An additional execution after exporting and reimporting the workflow replayed an existing event and created zero extra records. The test also checked normalized email, trimmed company and the event reference.

These results demonstrate the local mapping, branch, retry and replay behaviour. They are not measured Zapier task counts, n8n Cloud billing counts, a performance benchmark or customer savings. The fixture is a single-process in-memory service, so it does not establish production durability or concurrency correctness. Its practical lesson is that a successful execution badge alone cannot distinguish a new record, an existing record and an input held for review.

Before switching, record a cutoff time, pending source events, completed event IDs and delayed actions. Test against a separate destination first. Compare the actual fields and record references, including rejected inputs and partial failures.

1. Prepare: preserve the old Zap definition, credentials and trigger routing. Name the person who can stop the pilot.
2. Pause the old writer: arrange how new arrivals will be buffered or recorded during the handover.
3. Enable the new route: allow one active writer for each destination action and inspect the first accepted events.
4. Reconcile: account for arrivals, records written, events held and failures. Resolve pending delays explicitly.
5. Roll back if needed: stop the new writer, identify actions already committed, restore the previous route and replay only missing events.

A rollback restores routing; it does not undo messages sent or records already changed. Keep the same duplicate-protection rule during replay. Our export/import check demonstrates restoration inside the lab. Live Zapier rollback, webhook rerouting and delayed-action recovery are an implementation checklist, not claimed test results.

• Copying the diagram without the rules: capture empty values, data types, schedules and rejected branches as well as successful actions.
• Running two live writers: compare in a test destination before allowing a second system to create production records.
• Treating every retry as safe: confirm the destination can recognize the same event after an uncertain response.
• Assuming export means recovery: check connections, pending work and record reconciliation separately.
• Promising a saving from action counts alone: account for platform billing definitions, hosting, maintenance and operator time.

Start with the downloadable workflow to inspect the mechanics, then replace the synthetic source and destination deliberately. Marsen Agents can help scope connected workflows around your systems and owners. Where a step proposes an external action, use the human approval guide to define the review boundary.