How Do You Move a Zap to n8n Without Losing a Single Lead?

How do you move a Zap to n8n without losing a single lead?

Run both versions side by side before you switch anything. Rebuild the workflow in n8n, point it at a copy of the real input, compare its output against the live Zap for at least a week, then cut over the trigger in one planned step with a rollback ready. Downtime comes from rushed cutovers, not from the rebuild.

I see teams make the move for a few common reasons. They want more control over logic, they want workflows in a format they can version, or their Zapier bill grew faster than their pipeline. Those are fair reasons. None of them are worth a week of lost form submissions.

The method below works for any single workflow, whether it routes leads, syncs records, or posts alerts to Slack. Move one workflow at a time. A migration of twenty Zaps is just twenty small, boring migrations done in order.

Why do Zap migrations cause downtime in the first place?

Most downtime comes from the trigger. A Zap usually listens on a webhook URL or polls an app, and that connection belongs to Zapier. When you point the source at n8n instead, there is a window where events go to the old tool, the new tool, both, or neither. That window is where leads disappear.

The second cause is hidden behavior. A Zap that has run for two years often carries small fixes nobody wrote down: a filter step added after a bad week, a formatter that cleans phone numbers, a delay that waits for an enrichment to land. If the rebuild misses one of those, the new workflow runs cleanly and produces subtly wrong data.

The third cause is credentials. The new tool needs its own connections to HubSpot, Airtable, Google Sheets, or whatever the Zap touches. If those connections use a person's login instead of a shared service account, the migration inherits the same fragility you were trying to escape.

What should you document before you rebuild anything?

Write down every step of the live Zap in plain language, including filters, formatters, delays, and paths. Then pull a sample of real recent runs and record the input and the output for each. That record becomes your test set. Without it, you are comparing the new workflow to your memory, and memory always loses.

I open the Zap's run history and copy ten to twenty recent runs, choosing a mix: a normal lead, a lead with a missing field, a duplicate, a lead from an odd country format, and anything that errored. The edge cases matter more than the happy path, because the happy path is the part everyone remembers to rebuild.

I also write a one-line purpose at the top of the doc. Something like: when a demo form is submitted on the Webflow site, create or update the HubSpot contact, assign an owner, and alert the owner in Slack. If you cannot write that line, the Zap probably does more than one job and should be split before it moves.

How do you rebuild the workflow in n8n without guessing?

Rebuild step by step from the document, not from the Zap's screen. Map each Zapier step to one n8n node, and keep the same order until the new version matches exactly. Resist the urge to improve the logic during the move. A migration and a redesign at the same time makes it impossible to know which change caused a difference.

Field mapping is where most mistakes hide. Zapier and n8n reference data from earlier steps differently, so check every mapped field against the sample runs. A field that pulled a contact's company name in the Zap can quietly pull an empty value in n8n if one expression is off.

Build the error path now, not later. Every node that writes to a CRM or database should have a defined behavior when it fails: log the input, alert someone, and stop or continue on purpose. I wrote a whole piece on writing error paths in an n8n workflow, and a migration is the right moment to add them.

What is a parallel run and why does it matter?

A parallel run means the old Zap keeps doing the real work while the new n8n workflow receives a copy of the same inputs and writes its output somewhere harmless. You compare the two outputs every day. When they match across normal days and odd cases, you have evidence the new version is ready.

The harmless destination is the key. The n8n version should not write to your live CRM during the parallel run, or you will get duplicates. I point it at a test property set, a sandbox account, or simply a Google Sheet or Airtable table that logs what it would have written. Then a quick comparison shows every difference.

To feed n8n a copy of the input, the cleanest pattern is to have the source send to both places. If your form tool supports multiple webhooks, add the n8n webhook as a second destination. If it does not, a small step at the start of the existing Zap can forward each payload to n8n. Either way, the live path stays untouched.

Run it for at least a week, and longer if the workflow sees low volume. You want enough runs to hit the odd cases you documented. If none of those cases appear naturally, replay them by hand from your test set.

How do you cut over the trigger with no gap?

Pick a quiet time, then switch the source to send only to n8n and flip n8n's writes from the test destination to the live system in the same short window. Leave the Zap built but turned off. Watch the first live runs as they happen. If anything looks wrong, turn the Zap back on and point the source back.

The order inside that window matters. First, switch n8n's write destination to live. Second, change the source so it sends only to n8n. Third, turn off the Zap. Doing it in this order means there is never a moment where nobody is listening, only a brief moment where both might be. That is why your writes must handle duplicates cleanly.

Duplicate handling should already exist in a good workflow. Search for the contact by email before creating it, and update instead of create when it is found. If your Zap relied on HubSpot's own matching, make sure the n8n version does the same. A short overlap then produces an update, not a second record.

How do you roll back if something breaks after cutover?

Keep the old Zap intact and off for at least two weeks after cutover. Rolling back is then a two-step action: turn the Zap on and point the source back to it. Write those two steps in the migration doc before cutover, so whoever is on call can do it without thinking.

A rollback is only clean if you know which records the new workflow touched. Tag every record that n8n creates or updates during the first weeks, with a simple property or a note. If you roll back, that tag tells you exactly which records to review instead of auditing the whole CRM.

I also like a kill switch on any workflow that writes to a revenue system. One setting that stops all writes without deleting the workflow. My notes on giving an automation a kill switch cover the pattern, and it makes a nervous cutover much calmer.

What usually goes wrong after the move?

The common problems are quiet ones. A credential expires because it was tied to one person. A formatting step behaves differently on an unusual input. A rate limit appears at a volume the parallel run never reached. None of these break on day one. They show up in week three, which is why monitoring matters more than the cutover.

Set an alert for volume, not just errors. If the workflow usually runs twenty times a day and suddenly runs zero times, that is a failure even though no error fired. A daily count posted to Slack catches silent stops that error alerts miss.

Check the data, too. Once a week for the first month, pull a handful of records the new workflow created and compare them with what the Zap would have produced. It takes ten minutes, and it catches the slow drift that no alert will.

Should you migrate every Zap at once?

No. Move one workflow at a time, starting with the one that is easiest to verify, not the one that matters most. Your first migration teaches you how field mapping, credentials, and webhooks behave in n8n. Save the lead routing workflow for third or fourth, after you have learned those lessons on something lower risk.

Keep a simple tracker with one row per workflow: purpose, owner, status, parallel-run start date, cutover date, and the date the old Zap can be deleted. That tracker is also your inventory, and it pairs well with putting each workflow under version control so you can see what changed and when.

Some Zaps should not move at all. If a workflow is simple, stable, cheap, and owned by someone who knows Zapier well, moving it buys you risk and nothing else. Migrate for a reason, not for consistency.

What should you do next?

Pick one low-risk Zap, write its one-line purpose, and copy twenty recent runs into a test set. Rebuild it in n8n against that set, run it in parallel for a week, then cut over with a written rollback. When that one goes cleanly, you have a repeatable process for the rest.

The teams that migrate smoothly are not the ones with the best n8n skills. They are the ones who wrote down what the old workflow actually did before they touched it.

If you want help planning a migration or want a second opinion on which workflows are worth moving, reach out. I build and maintain automations like these for B2B teams, and I am happy to look at your setup with you.