n8n vs Zapier: Which Zaps Break When You Move to Self‑Hosted n8n with Docker, and How Much Work Is Rebuilding Them?

Description and use

Migrating from Zapier to self‑hosted n8n requires rebuilding workflows because n8n lacks a Zap importer. Key challenges are apps without native nodes, Zapier‑only tools, and OAuth connections. The recommended approach is to audit, export, map, and rebuild using n8n nodes or HTTP requests.

Problem

Migrating from Zapier to a self‑hosted n8n instance requires rebuilding workflows because n8n has no native importer for Zaps.

Outcome

Rebuilding Zaps in n8n is feasible for simple webhook and API workflows, but complex Zaps that rely on Zapier‑only tools, OAuth‑only connections, or niche SaaS connectors require significant effort or may not be portable.

Workflow

• Audit existing Zaps for three risk categories: apps without native n8n nodes, Zapier‑only tools (Tables, Interfaces, Storage), and OAuth‑only connections.
• Export Zap inventory (trigger, steps, field mappings) into a spreadsheet or screenshots.
• Identify native n8n nodes for each app; if missing, check for community nodes or public APIs.
• For missing triggers, use vendor webhooks or schedule triggers to poll APIs.
• For missing actions, use HTTP Request node or build custom code nodes.
• Rebuild each Zap in n8n, mapping fields and credentials.
• Test rebuilt workflows with sample data.
• Consolidate duplicate workflows using sub‑workflows or reusable templates.
• Deploy n8n in Docker, configure reverse proxy and HTTPS.
• Monitor execution, retries, and error handling.
• Maintain credentials and update community nodes as needed.

Evidence

Treat a move from Zapier to self‑hosted n8n as a rebuild, not a migration, because n8n has no native importer for Zaps.

Source

Simple webhook and API Zaps usually transfer cleanly.

Source

Audit your Zaps by those three risks before you commit, because that list, not your Zap count, determines the workload.

Source