The Zapier-to-n8n migration question is now common enough that we get asked about it on almost every discovery call. The driving force is usually cost: a Zapier bill that started at $50/month is now $1,500/month, and the team realizes that n8n self-hosted runs the same workflows for a tenth of that. Sometimes it's a flexibility constraint. A workflow they can't build in Zapier that they could build in n8n.

This post is the honest migration playbook. When it's worth it, when it isn't, and the operational reality of moving real workflows between platforms without breaking your operation.

When Migrating Is Worth It

The migration is worth it when at least two of these apply:

1. Your Zapier bill exceeds $500/month. Below that, the migration effort costs more than the savings for 12-24 months. Above that, savings materialize fast.

2. You're hitting Zapier limits. Task quotas, complex multi-step constraints, lack of conditional logic flexibility, or specific integrations that don't work the way you need.

3. You have someone technically capable of running self-hosted infrastructure. Either internal team or contracted. n8n self-hosted requires Docker knowledge, monitoring, backups, version control. If nobody on your team can do that, n8n Cloud is the right destination, which removes some of the cost advantage.

4. You want to use AI in your workflows extensively. n8n's AI nodes (~70 of them) and native LangChain integration are significantly more flexible than Zapier's AI features.

5. Your workflows involve cross-system logic that Zapier handles awkwardly. Multi-branch decisions, loops, complex data transformation, error handling with retries.

If none of these apply, you don't need to migrate. Zapier is excellent for what it does. The "n8n is better, period" arguments online are usually written by people who didn't have a working Zapier setup to begin with. (We put all three platforms side by side here if you're still choosing.)

The Cost Math

For a typical mid-stage company running serious automation, the numbers:

Zapier scenario. 25 active Zaps, average 8 steps per Zap, ~150,000 task runs/month. Zapier Professional or Company plan. Cost: $1,200-$2,500/month = $14K-$30K/year.

n8n scenario, equivalent workflows. Self-hosted on a $40/month VPS (DigitalOcean or AWS). Even at 500,000+ workflow executions/month, the VPS cost barely moves. Add backup storage and monitoring: $50-$80/month total = $600-$1,000/year.

Annual savings: $13K-$29K.

The hidden costs to account for:

Migration effort: 60-200 hours depending on workflow count = $7K-$25K of internal time or agency engagement.
Ongoing maintenance: someone has to manage the VPS, monitor uptime, handle updates. ~5-10 hours/month = $6K-$12K/year of internal time.
Initial learning curve: 20-40 hours for a team to get fluent in n8n.

Net annual savings after maintenance: typically $5K-$15K. Plus the strategic value of having a more flexible platform.

For most teams, the migration pays back in 12-18 months and provides significantly more capability going forward.

The 6-Phase Migration Playbook

Phase 1: Inventory and Triage (Week 1)

Pull a complete list of every Zap, what it does, what it triggers on, how many tasks it consumes per month, when it last failed, who owns it.

Categorize each Zap:

Keep, migrate as-is. Working well, frequently used, fits the n8n model cleanly.
Improve during migration. Has known issues, brittle structure, or opportunities for redesign.
Kill. Created by someone who left the company, no longer needed, replaceable by a better workflow.
Replace with native. Things Zapier does that the destination system can do natively (Salesforce Flow, HubSpot workflow). Don't recreate in n8n what should live in the system itself.

The dead-weight elimination is often surprising. Most companies discover 20-40% of their Zaps can simply be deleted.

Phase 2: n8n Environment Setup (Week 1-2)

Stand up the n8n environment before migrating anything.

For most clients we recommend:

Self-hosted on a VPS. DigitalOcean or AWS, 4GB RAM minimum, 8GB recommended. Run via Docker Compose for clean upgrades.
PostgreSQL for the database (not SQLite). Important for scale and backups.
Persistent SSL via Caddy or Nginx.
Backups configured. Daily database snapshots to S3 or similar. Test the restore.
Monitoring. Uptime checks via Better Uptime, OnlinePING, or self-hosted Uptime Kuma. Slack alerts on workflow failures.
Version control. Workflows exported as JSON and committed to a Git repo. n8n's project + Git integration in 2026 makes this much cleaner than it used to be.
Separate staging environment for testing changes before production.

We've covered the full self-hosting setup in our n8n self-hosting guide. Use that for the technical setup.

For teams without in-house DevOps capacity, n8n Cloud is the safer path. You give up some cost savings but skip the operational overhead.

Phase 3: Pilot Migration (Week 2-3)

Pick 3-5 Zaps to migrate first. Choose ones that are:

Low-stakes (not running mission-critical workflows).
Diverse in patterns (cover different trigger types, integrations, logic patterns).
Owned by people who can give fast feedback on whether the migration worked.

For each pilot Zap:

Document the Zap's behavior in plain English.
Build the n8n version, running in parallel with the original Zap.
Run both for 1-2 weeks, comparing outputs.
When confident the n8n version is correct, disable the Zap.

This phase isn't about speed. It's about learning the platform and validating that your migration approach works.

Phase 4: Batch Migration (Weeks 3-8)

Now you migrate the rest. Some batching strategies that work:

By system owner. Migrate everything owned by the sales ops team in a batch.
By trigger type. Migrate all the Salesforce-triggered Zaps together; you'll reuse the trigger configuration.
By criticality. Save the highest-stakes Zaps for last so you've practiced on the lower-risk ones.

Maintain a migration tracker (Notion, Airtable, or a simple sheet) with status for each Zap: Not Started → In Progress → In Parallel Run → Switched Over → Verified Stable → Done.

Phase 5: Patterns That Don't Translate Directly

Some Zapier patterns require redesign in n8n. The big ones:

Zapier Paths vs n8n Branches. Zapier Paths are a single Zap with multiple branches. In n8n, you use IF nodes or Switch nodes for the same logic, but the structure is more visual and explicit.

Zapier Tables. Zapier's built-in lightweight database has no n8n equivalent. Migrate this data to Airtable, Notion, a Google Sheet, or PostgreSQL.

Zapier's Looping Logic. Looping a single step over an array. n8n handles this differently: instead of a "loop" node, n8n's nodes naturally process arrays item-by-item. The flow is sometimes more intuitive, sometimes requires rethinking.

Zapier Formatter. n8n's Function nodes (JavaScript) can replicate most Formatter operations. Some specific formatters (date parsing across timezones) need explicit handling.

Zapier's Built-in OAuth Connections. n8n requires you to set up the OAuth apps yourself in some cases (Google, Microsoft, others have one-click but some integrations require creating a custom OAuth app in the source system). Plan for this.

Sub-Zaps. Zapier's "send to another Zap" pattern. In n8n, use Sub-Workflows (or the Execute Workflow node). The pattern is cleaner in n8n once you learn it.

Phase 6: Cutover and Hypercare (Weeks 7-9)

Once all critical Zaps are migrated and running in n8n with parallel validation complete:

Schedule a cutover day. Communicate to the team.
Disable the Zapier zaps (don't delete them yet: keep them disabled for 30 days as rollback insurance).
Monitor n8n closely for the first 2 weeks. Daily review of failed executions.
After 30 days of clean operation, downgrade or cancel the Zapier subscription.

The cutover is anticlimactic if you've done the parallel-run validation. It should be: that's the point.

Common Failure Modes

1. Migrating broken Zaps. Don't rebuild a brittle Zap in n8n. Redesign it. Migration is the forcing function to fix the things you've been meaning to fix.

2. Skipping parallel run. "We tested it once and it worked" is not enough. Parallel run for 1-2 weeks catches the edge cases.

3. Underestimating the OAuth dance. Setting up OAuth apps in source systems can eat hours. Plan for this in your timeline.

4. No monitoring. Zapier had its own monitoring and alerted you on failures. Self-hosted n8n doesn't, by default. Set up monitoring before you cutover anything important.

5. Migrating to self-hosted without DevOps capacity. If nobody on the team can SSH into a server and debug a Docker issue, self-hosted will bite you. Use n8n Cloud instead: still significantly cheaper than Zapier at scale, with no infrastructure burden.

What Changes This Math

The case above rests on numbers that move independently, which is a good argument for re-running it once a year rather than treating the decision as settled.

Zapier's pricing moves. So does n8n Cloud's. Self-hosted stays free-as-in-software only as long as the license says so, and that license has been rewritten before. Your own side of the ledger moves faster than either: the engineer who volunteered to own the VPS gets promoted, the workflow count doubles after an acquisition, or a customer contract lands a data-residency clause on you and self-hosting stops being the cheap option and becomes the only one.

The line that actually decides it isn't the subscription. It's the 5-10 hours a month of somebody's attention, and that's the line most comparisons leave out entirely, including most of the ones arguing for n8n. Those hours are either the cheapest thing in this post or the reason the migration quietly failed eight months later, and which one depends on nothing more complicated than whether that person exists and knows it's their job.

Want a read on your own Zap inventory before committing? We'll go through it with you, including which ones shouldn't be rebuilt anywhere.

From Zapier to n8n: A Complete Migration Guide for Operations Teams