Three Failed Zapier-to-n8n Migrations and What They Had in Common

Three different companies. Three different industries. Same pattern.

Each had been on Zapier for years. Each had hit the pricing wall. Each decided to migrate to self-hosted n8n. Each got 60-70% through and gave up.

The technical migration was straightforward. The reason it failed was upstream.

Failure 1: The 200-zap audit nobody wanted to do

Company A had 198 Zaps. Most had been built by people who'd left. Nobody knew which ones did what.

The migration plan said "audit before migrating." The team got 40 zaps in and quit. The audit revealed that 30% of the zaps did nothing useful (sent emails to defunct addresses, fired into deleted Slack channels), 20% had duplicates, and the rest needed real interrogation to understand.

The team got fatigued. The CFO who'd approved the migration started asking when it would be done. The migration was paused "for now." Three months later they were still on Zapier paying $400/mo for 198 zaps, half of which were dead.

Root cause: the audit was the actual project, not a precursor. The team underestimated it.

Failure 2: The expert who left mid-migration

Company B had a clear migration plan. They had n8n stood up on a VPS. They had a senior automation engineer running the migration.

He took a job at another company in week 4 of an 8-week migration. The company had no documentation of his work. The replacement contractor was 6 weeks late to come up to speed. By the time he was productive, half the team was advocating for going back to Zapier.

They went back to Zapier. The half-migrated state on n8n was abandoned.

Root cause: bus factor of 1. The migration depended on one person who could leave. He did.

Failure 3: The migration that quietly became a rewrite

Company C started the migration with "lift and shift" intent. Same zaps, n8n implementation, same logic.

Two weeks in, the engineer running it noticed that several zaps had bad architecture — they were doing things that n8n could do better differently. He started rewriting instead of porting. The rewrites took 3x longer than ports.

By the deadline, 30% of the workflows were beautifully rewritten. The other 70% were not migrated. The deadline passed. The CFO pulled funding for further work.

They lived in a hybrid state — some on n8n, most on Zapier — and paid for both. The cost-saving thesis evaporated. The migration was declared a failure.

Root cause: scope creep from migration to rewrite. The engineer was right that the rewrites were better, but the org didn't sign up for the bigger project.

What they had in common

All three migrations: - Underestimated the audit - Had a single point of failure (one person, one budget cycle) - Hadn't decided whether this was a migration or a rewrite - Didn't kill dead workflows before migrating - Tracked progress in "zaps migrated" instead of "value delivered"

The technical work was the easy part in all three. The discipline was the hard part.

What I'd do instead

If you're considering a Zapier-to-n8n migration (or any large automation platform migration), three rules:

One, audit first as a discrete project. Kill what's dead. Decide what to migrate vs rewrite vs delete. The audit IS the project. The migration is the execution of the audit's findings. Don't conflate them.

Two, have at least two people who understand each non-trivial workflow. Document the intent of every workflow before you port it. The documentation pays for itself the first time someone leaves.

Three, commit to one mode per workflow. Lift-and-shift or rewrite. Choose at audit time. The middle path is where projects die.

The lesson

Migrations are organizational discipline projects with a technical surface area. The technical part is the easy part. The discipline is what fails.

If your org doesn't have the discipline to audit, document, and commit, the migration will fail regardless of how skilled the engineer is.

I no longer take on Zapier migrations without an audit phase in the scope. The audit phase is paid. It produces a report. The report drives the migration scope. If the report shows the migration isn't worth it, we don't migrate. The audit is the deliverable that matters.