Zapier to n8n Migration: A Six-Zap Bridge in Numbers

Zapier to n8n migration case study: six Zaps, 9 records dropped by filters in a week, and the ledger and checks that fixed it. Numbers and mistakes included.

By Carlos Familia, CRM & AI automation expert. Updated October 19, 2026. 5 min.

• 6 Zaps in one personal Zapier account carried a brokerage's bridge to its loan origination system (LOS)
• 9 records discarded by Zap filters in 7 days, with no failure and no alert
• 226 of 2,032 contacts carried any LOS ID
• 0 of 733 leads looked converted, though 707 carried a loan ID
• 808 fields written on 402 contacts by the first loan-details sync
• 15 minutes: how long a missing LOS ID waits before an alert fires

What was the situation?

A mortgage brokerage in Florida kept its lead bridge to the LOS in the owner's personal Zapier account: six Zaps, none of them passing an ID that would let anyone trace a record. Filters inside them dropped records quietly. The vendor had set a deadline to retire the app version the Zaps relied on. One notes webhook was attached to no Zap, so CRM notes never reached the LOS.

How do you migrate from Zapier to n8n? Not in one jump. I wrote down what every Zap did, moved the logic that needed IDs and guards into n8n, upgraded the Zaps that stayed before the vendor's cutoff, and added a check that notices when a record does not arrive. In my view the check mattered more than the move.

What did the Zaps hide?

Four things, none of them visible as an error in Zapier.

• Filtered records. Nine were discarded in a week, and Zapier did not report them as failures. Its Zap history help page puts filtered in the same group as held, stopped and success: statuses for which "the Zap finished running the action." Its pricing page lists Filter by Zapier among the steps that do not count as tasks. A dropped record looks like a finished run, raises no error and costs no task.
• A field that pointed the wrong way. The field that seemed to mark a converted lead is really a back-reference to the loan. Read the obvious way, it said 0 of 733 leads had converted, while 707 had a loan ID attached.
• Missing IDs. Just 226 of 2,032 contacts had an LOS ID of any kind, so most records could not be matched to a loan.
• Notes with nowhere to go. The notes webhook was attached to nothing.

What did I move, and what stayed?

I started with an inventory. Written out, the six Zaps came to 812 lines. I wanted every Zap's job on paper before I moved any of it.

Status changes and new-loan logic moved to n8n behind a stale-event guard, which compares stage order and status date before acting. Notes and referral-agent texts became idempotent, so a repeated event writes once. The build also links co-borrowers and creates contacts that do not exist yet.

The Zaps that stayed live were switched to the new app version ahead of the vendor's deadline.

Then came what neither tool provided. An intent ledger records what should happen, and a reconciler checks it every 5 minutes. If a record still has no LOS ID 15 minutes later, a person gets an alert with a retry link, good for 3 tries at most. Notes written in the CRM now land on the LOS loan with an anti-echo marker that stops them bouncing back. Every 30 minutes a loan-details sync pulls closing date, rate lock and funding date.

What happened?

With the ledger in place, a record with no ID after 15 minutes becomes a message to a person instead of a quiet gap. That is the difference I care about most: the old bridge could lose a record and report nothing.

When is it safe to switch a Zap off? I would want three things first: the new path has handled real records, a per-record comparison shows the same result as the Zap, and the alert for a missing ID has fired at least once on purpose. Until then the old Zap stays on.

What broke on the way?

• Repeat clients. GoHighLevel refused a second opportunity per contact in a pipeline. The setting that lifts that rule flipped back off by itself within about 2 hours, which blocked a real repeat client. An hourly probe now watches the setting, and conflicts go to Slack as "create new or update", behind a confirmation page.
• Slack previews. Slack unfurled links in messages, which triggered action links nobody had clicked. The confirmation page fixed that too.
• A workflow that pulled the wrong people. A "call occurred" workflow dragged realtor opportunities into the sales pipeline. A pipeline filter and a guard stopped it, and 225 contacts were retyped.
• Echoes. Call transcripts bounced back into the LOS until the anti-echo marker covered them as well.

What would I do differently?

1. Build the arrival check first. I think the ledger earns more than the logic does, so I would have it running before a single Zap moves.
2. Compare old and new per record. Run both side by side and compare them record by record before any Zap goes off.
3. Ask for IDs on day one. A bridge without IDs is a guess, and 226 of 2,032 is what a guess looks like.
4. Put a confirmation page in front of every decision link from the start.
5. Read the vendor's deprecation notices before planning. In my view a deadline like that should set the order of the work.

Not every Zap deserves a move. A short Zap that one person maintains is fine where it is, and the billing differences are laid out in n8n vs Make vs Zapier. Move the ones that need IDs, guards or a reconciler, and agree what you are buying in an n8n project scope of work.

The wider mortgage build is described in mortgage CRM and the account audit in the case study. For a review before you move anything, an n8n consultant starts with an inventory like the one above, and CRM migration consultant covers moving the CRM itself. You can also book a call with your Zap list.

About the author

Carlos Familia, CRM & AI automation expert. GoHighLevel, n8n, AI agents, servers. Full-stack developer.

I build CRM systems in GoHighLevel, n8n automations on my own servers and AI voice and chat agents for service businesses. Full-stack developer: I write the workflow, the API integration, the database and the server it runs on, and I test every build with real journeys before handoff.