Jordan: Someone in the community asked me this last week — and I want to read it almost exactly because I think a lot of you are sitting on the same question. "Jordan, I have a twelve-step Zap that handles every inbound lead. Webhook catch, CRM lookup, enrichment, filter, route, create-or-update, Slack notification — the whole pipeline. It's running maybe three thousand times a month and I'm burning through tasks. I know Make or n8n would be cheaper. But this Zap is revenue-critical. If it breaks for even an hour, I lose leads. How do I migrate from Zapier without blowing up the thing that's feeding my business?"
Jordan: And I sat with that for a minute. Because the honest answer — the one nobody wants to hear — is that most migration guides skip the part that actually matters. They show you how to rebuild the workflow. They don't show you how to prove the new version works identically to the old one before you flip the switch.
Jordan: Rebuilding is the easy part. Trusting the rebuild — that's the hard part.
Jordan: So here's what I did. I took a real client workflow — twelve steps, webhooks, filters, lookups, rate-limited API calls — and I ran both versions side by side for fourteen days. Same payloads. Correlation IDs on every event. A parity log that told me exactly where the new version disagreed with the old one. And on day fifteen, I cut over in fifteen minutes with a rollback toggle I could flip in under sixty seconds.
Jordan: Zero downtime. Zero lost leads. And about four hundred dollars a month back in my pocket.
Jordan: By the end of this episode you'll have the exact migration playbook I used — a fourteen-day shadow-run that proves your Make or n8n rebuild matches your Zapier workflow event for event, a fifteen-minute cutover window with a tested rollback you can trigger in sixty seconds, and the cost model that tells you whether the move is even worth making before you touch a single webhook. I'm Jordan. This is Headcount Zero.
Jordan: Okay. Before I walk you through the shadow-run, I need to show you the workflow I was migrating — because the details matter for understanding why you can't just rebuild and pray.
Jordan: This was a lead-intake Zap for one of my retainer clients. Twelve steps. Starts with a Catch Hook — a webhook trigger that receives form submissions from their website. Step two is a filter that drops spam based on email domain. Step three does a CRM lookup — searches HubSpot for an existing contact. Step four is a path split: if the contact exists, update the record; if not, create a new one. Steps five through eight handle enrichment — Clearbit lookup, a code step that normalizes the data, a formatter that cleans phone numbers. Step nine routes to the right sales pipeline based on company size. Step ten sends a Slack notification to the sales channel. Step eleven logs the event to a Google Sheet for reporting. Step twelve fires a confirmation email through SendGrid.
Jordan: Twelve steps. About three thousand runs a month. And here's the cost math that made me start looking at alternatives.
Jordan: In Zapier's current plans — as of mid-twenty twenty-six — tasks only count for successful action steps. Filters don't consume tasks. Paths don't consume tasks. Tables and Forms steps don't consume tasks. So my twelve-step Zap was actually burning about eight tasks per run. Times three thousand runs — twenty-four thousand tasks a month. On a Professional plan, that's real money.
Jordan: Now compare that to Make's credit-based model — roughly one credit per module action. Same workflow, about twelve credits per run, thirty-six thousand credits a month. Or n8n Cloud, which charges by execution — one execution per workflow trigger. My three thousand runs would be three thousand executions, well within their Pro plan's ten thousand monthly limit. Either way, the per-unit economics at high volume tilt heavily away from Zapier. For this specific workflow, the gap was roughly four hundred dollars a month.
Jordan: So the savings are real. The question was never whether to migrate. It was how to migrate without losing a single lead.
Jordan: First thing I did — before I rebuilt a single node — was run what I call Gate Zero. Three pass-or-fail checks that determine whether you should even attempt this.
Jordan: Check one: SSO parity. If your client requires single sign-on, you need to know which plan supports it on the target platform. Zapier has SSO on Team and above. Make? Enterprise only. n8n? Business or Enterprise. If your client needs SSO and you're targeting Make, you're looking at an Enterprise contract before you write a single scenario. That's a deal-breaker for some migrations, and you want to know it on day one, not day twelve.
Jordan: Check two: webhook throughput. During a shadow-run, you're sending every payload to both platforms simultaneously. That means double the webhook traffic. Zapier allows twenty thousand requests per five minutes per user — generous. But under high load, Zapier may return a two hundred status code but delay processing. So your parity logs might show a timing gap that looks like a failure but is actually Zapier queuing. Make caps incoming webhooks at three hundred requests per ten seconds per scenario. Exceed that and you get a four twenty-nine. If your workflow is bursty, you need to account for that before you start the parallel run.
Jordan: Check three: premium app dependencies. My Zap used Clearbit and SendGrid — both available as native integrations on all three platforms. But if your Zap uses a Zapier-exclusive connector or an MCP agent step, you need to confirm there's an equivalent module or node on the target. Or you need to build a custom HTTP call. Either way, you need to know before you start.
Jordan: If any of those three checks fail, stop. Fix the blocker first. Don't start a shadow-run with a known gap — you'll waste two weeks proving something you already know won't work.
Jordan: Okay — Gate Zero passed. Now the actual shadow-run.
Jordan: The architecture is simple. I set up a small Cloudflare Worker as a relay. Every inbound webhook from the client's website hits the Worker first. The Worker does three things: it generates a correlation ID — I used ULIDs — it stamps that ID onto the payload, and it forwards the payload to both Zapier and Make simultaneously. Zapier remains the authoritative system — it's still doing the real writes. Make runs in shadow mode, meaning every write module is wrapped in a guard that logs what it would have done without actually doing it.
Jordan: Why a relay instead of just pointing the form at both webhook URLs? Control. The relay gives you one place to add the correlation ID, one place to toggle routing, and one place to implement your rollback. When cutover day comes, you change one environment variable in the Worker — not two webhook URLs in the client's form builder.
Jordan: The correlation ID is the whole game. Every event gets a unique ID that follows it through both systems. At the end of each day, I compare: did both platforms receive the same event? Did they take the same branch? Did they produce the same output? I'm checking three things — count parity, branch parity, and field parity. One input should produce exactly one run on each side. The same logical path should fire. And the key output fields — contact ID, pipeline assignment, email sent — should match after normalization.
Jordan: I logged all of this to a simple Notion database. Timestamp, correlation ID, Zapier result, Make result, pass or fail, failure class if applicable. Took me about twenty minutes to set up the logging scenario in Make.
Jordan: The daily routine during the shadow-run took me about fifteen minutes. Pull up the log. Check the pass rate. Triage any failures.
Jordan: Day one, my pass rate was seventy-two percent. Seventy-two. And I almost panicked — until I looked at the failure classes. Almost every failure was a field-parity issue caused by date formatting. Zapier was returning dates as month-slash-day-slash-year. Make was returning ISO eight six oh one. Same date, different string. One normalization rule fixed the entire category overnight.
Jordan: Day three, I hit a real problem. The CRM lookup step in Make was returning a different contact than Zapier for about two percent of searches. Turned out Zapier's "Find or Create" action uses a fuzzy match on email, while the Make HTTP module I'd built was doing an exact match. Two percent of our contacts had slight email variations — a plus sign, a dot in a Gmail address — and the platforms disagreed on which record to return. That's exactly the kind of thing you cannot find by rebuilding and testing with five sample payloads. You need volume. You need real data. You need fourteen days.
Jordan: I fixed the search logic in Make to match Zapier's fuzzy behavior, and by day seven my pass rate was ninety-nine point three percent. By day ten, ninety-nine point six. The remaining failures were all timing-related — Zapier's delayed processing under load creating a window where the correlation log showed a gap that resolved within thirty seconds.
Jordan: My go-or-no-go threshold was ninety-eight point five percent pass rate for three consecutive days, with zero hard failures in the last twenty-four hours on critical paths. I hit that on day eleven. I could have cut over early. I waited until day fourteen anyway — because the whole point of a shadow-run is that patience is cheaper than downtime.
Jordan: Day fifteen. Sunday morning, seven AM — lowest traffic window of the week.
Jordan: The cutover took four steps. Flip the Cloudflare Worker's environment variable from "primary equals Zapier" to "primary equals Make." Turn off the Zap. Disable shadow mode in Make so the write guards come off and it starts doing real CRM writes, real emails, real Slack notifications. Trigger a known-good test event end to end and verify the output.
Jordan: Total elapsed time from step one to confirmed test event: eleven minutes. I had budgeted fifteen.
Jordan: And then I sat there for an hour watching the logs. Not because I needed to. Because I'm a solo operator and this workflow feeds my client's entire sales pipeline, and I wanted to see fifty live events clear before I closed my laptop.
Jordan: The rollback plan — which I'd rehearsed twice during the shadow-run — was the reverse. Flip the Worker variable back to Zapier, re-enable the Zap, re-enter shadow mode on Make. Rehearsal time: forty-seven seconds. I never needed it.
Jordan: Now — I need to be honest about something. Zapier in twenty twenty-six is not the same product it was two years ago. They've bundled Tables and Forms into every plan. They've shipped Agents, Copilot, MCP integration. The ecosystem is massive — over seven thousand app integrations. And their webhook headroom is generous.
Jordan: If your workflow is simple — five or six steps, moderate volume, no rate-limit pressure — Zapier might still be the right answer. The task accounting is actually favorable for workflows with lots of filters and paths, because those steps are free. And the reliability is battle-tested in a way that Make and n8n are still catching up to.
Jordan: I've had clients where I ran the cost model and Zapier won. The per-task cost at their volume, with their specific step mix, was lower than the equivalent on Make or n8n. And in those cases, I told them to stay. Migration for ideology is a waste of your time. Migration because the numbers say so — that's a different conversation.
Jordan: The shadow-run answers that question for you. If you get to day fourteen and the cost model doesn't show meaningful savings, or the parity rate isn't where you need it — don't migrate. You've spent two weeks and learned something valuable. That's not a failure. That's due diligence.
Jordan: But if the numbers work — and for high-volume, multi-step workflows they usually do — then you've also built the proof. You have fourteen days of logs showing the new system matches the old one. You have a tested rollback. And you have a cutover plan that takes fifteen minutes, not a weekend of crossed fingers. Other practitioners have landed in the same place — Rene Zander's published migration playbooks for both Zapier-to-n8n and Zapier-to-Make follow a similar validate-then-cut pattern.
Jordan: And on Reddit — this is purely anecdotal and not verified — one poster reported saving roughly eight hundred dollars a month after moving all company automations from Zapier to self-hosted n8n. I can't vouch for the specifics, but it's directionally consistent with what the cost models show for high-volume operators.
Jordan: So — back to that question from the community. "How do I migrate from Zapier without blowing up the thing that's feeding my business?" You don't guess. You don't rebuild on a weekend and hope. You run both systems in parallel for fourteen days, you let the correlation logs tell you exactly where the new version disagrees with the old one, and you fix those disagreements one at a time until the parity rate proves the rebuild is trustworthy. Then you cut over in a fifteen-minute window with a rollback you've already rehearsed.
Jordan: The whole process — Gate Zero checks, the Cloudflare Worker relay, the shadow-run, the cutover — took me about six hours of active work spread across two weeks. The daily monitoring was fifteen minutes. And the result was a migration I could defend to my client with data, not promises.
Jordan: If you want the full playbook — the shadow-run checklist, the risk register template, the cost model with current Zapier task versus Make credit versus n8n execution math, and the post-cutover validation script — grab the Zero-Downtime Migration Guide on the Resources page. It's the exact system we walked through today, ready to copy.
Jordan: One thing to do this week. Pick your highest-volume Zap. Open the task history. Count the actual tasks per run — remember, filters and paths are free. Multiply by your monthly volume. Then go to Make's pricing page or n8n's pricing page and run the same math on credits or executions. If the gap is more than a hundred dollars a month, you have your answer. Start Gate Zero.
Jordan: I'm Jordan. This is Headcount Zero. Go build something.