How to Migrate Zaps to Make or n8n Without Downtime

A practical field guide from Automation Ace.

The short answer

Don't switch a workflow off in Zapier and hope the new one catches everything. Move in waves. For each workflow, document what it does, rebuild it in Make or n8n, and run the new version in shadow mode, where it logs what it would do without writing to live apps. Compare the results, then cut over the trigger at a planned time. Use a processed flag or idempotency key so neither platform handles the same record twice, and keep the Zap paused, not deleted, until the new workflow has run cleanly for a full business cycle.

Still choosing a platform? Start with Zapier vs Make vs n8n and Make vs Zapier for small business.

1. Decide what to move, and why

A migration is worth it when it solves a specific problem, such as cost at high volume, a need for self-hosting or data residency, complex branching, or a team that wants code-level control. Write down the reason for each workflow you plan to move. Some workflows are better left in Zapier, for example ones that rely on an app integration the new platform lacks, or that run so rarely the savings are negligible. Compare costs with Zapier tasks vs Make operations before you commit.

Group the workflows into waves:

• Wave 1: low-risk, high-volume workflows where the savings or benefits are clear, such as internal notifications, logging, and data syncs that can be replayed.
• Wave 2: customer-facing workflows with clear inputs and outputs, such as lead routing and onboarding.
• Wave 3: business-critical, finance, or rarely-run workflows, once the team trusts the new platform.

2. Inventory every Zap before you touch anything

For each Zap, record its trigger app and event, every step, filters and paths, connected accounts, Storage or Tables dependencies, sub-Zaps, webhook URLs, schedules, and the owner. Include the business result it produces and how you'd know if it failed. A systems and data inventory and automation documentation make this repeatable.

Pay special attention to anything that points at a Zapier URL. Webhook triggers, forms, and other apps that call Zapier will need to be repointed, and those changes are what make a cutover risky.

3. Map Zapier concepts to the new platform

Feature names and limits change, so confirm each one in the platform's current documentation. The biggest difference is how data flows. Zapier handles one trigger item per run, Make passes bundles between modules, and n8n passes arrays of items between nodes. Line items and loops usually need the most rework. See line items and arrays.

4. Rebuild from the documented logic, not the screen

• Reconnect accounts with the right owner. Use a shared or service account rather than a person who might leave. See what happens when someone leaves.
• Recreate the logic, then improve it. Fix known weaknesses, but avoid redesigning the business process during the migration, or you won't be able to compare results.
• Add idempotency. Give each record a stable key, such as a source ID or event ID, and look it up before you create anything. See safe reprocessing without duplicates.
• Add error handling from day one so failures are visible. See the Make error handling guide and monitoring.

5. Run the new workflow in shadow mode

In shadow mode the new workflow gets the same triggers as the Zap but writes to a log, such as a sheet, table, or data store, instead of to live apps. The Zap keeps doing the real work. Each day, compare what the Zap did with what the new workflow would have done.

• For webhook triggers, send events to both platforms by using a sender that supports multiple webhooks, or a small relay. See receiving webhooks with Cloudflare Workers.
• For polling triggers, let the new trigger watch the same source. It will keep its own record of what it has seen.
• Match runs on the record ID and compare branch taken, values written, and side effects.

Keep shadowing until every common case and a few edge cases match. For most workflows that takes one to two weeks, and for monthly processes it takes one full business cycle.

6. Cut over at a planned time

1. Pick a quiet window, tell the workflow's owner, and freeze changes to the Zap.
2. Switch the new workflow from logging to live actions.
3. Repoint webhooks and app settings to the new platform, then turn the Zap off. If you can't do both at once, rely on the idempotency key so the record that arrives during the switch isn't processed twice.
4. For polling triggers, decide where the new trigger starts. A trigger that starts from “now” can miss records created during the switch, and one that starts from the beginning can reprocess old ones. Use a processed flag or a created-after filter to cover the gap.
5. Watch the first live runs closely and compare them with the shadow log.

Before moving a webhook, review why a Make webhook doesn't receive data and why a webhook fires twice.

7. Keep a rollback plan

Pause the Zap rather than deleting it, and write down the exact steps to switch back: which webhooks to repoint, which flag to reset, and who decides. If the new workflow fails, turn it off, turn the Zap back on, and replay the affected records using your processed flag. A rollback you have practiced once is far safer than one you improvise during an outage.

8. Decommission cleanly

After a full business cycle with no issues, export or screenshot the Zap for reference, delete it, remove unused connections and webhook URLs, and update your inventory and runbook. Cancel or downgrade the Zapier plan only after every wave is done, and check that nothing else, such as forms, Interfaces, or Tables, still depends on it.

Frequently asked questions

Can I import Zaps directly into Make or n8n?

Not reliably. Each platform has its own triggers, modules, data shapes, and expressions, so plan to rebuild each workflow from its documented logic rather than convert it automatically.

Will the new platform reprocess old records?

It can. Polling triggers keep their own memory of what they have already seen, and that memory does not move between platforms. Choose where the new trigger starts, or add a processed flag or idempotency key so old records are skipped.

How long should Zapier and the new platform run side by side?

Run the new workflow in shadow mode until it has handled every common case and a few edge cases with matching results. For most business workflows that is one to two weeks, or one full business cycle for monthly processes.

Should I migrate everything at once?

No. Migrate in waves, starting with low-risk, high-volume workflows where savings are clearest, and leave business-critical or rarely-run workflows until the team is confident on the new platform.