Moving from Zapier to Make as a cutover, not a copy
How to move automations from Zapier to Make: the audit that decides what moves, how each Zapier concept maps across, why the bill does not convert one for one, and a cutover that neither double-fires nor drops records.
This is a different kind of page from the other integrations, because nothing flows between the two tools. A migration is a project: finding out what you have, deciding what moves, rebuilding it, and switching over without sending every customer two emails or none.
The first thing to know is that a Zap cannot be exported and imported as a scenario. Zapier can export Zap definitions as JSON on its Team and Enterprise plans, but that file is for backup and for other Zapier accounts, and Make does not import it. There is no conversion tool to rely on, so a migration is a rebuild, and what makes it safe is a plan for running old and new side by side. The second thing is that the saving is not automatic. Whether Make is cheaper depends on what the Zaps do, and for some it is not.
A migration in six steps
- 01
Inventory every Zap, and delete the dead ones
List each Zap with its owner, trigger, apps, connected account, task use over the last month and last run date. A surprising share turn out to be off, broken or superseded. Those get deleted, not migrated, which is the cheapest saving in the whole project.
- 02
Sort into stay, move and retire
Simple, low-volume, linear Zaps maintained by non-technical staff stay on Zapier. Anything that branches, iterates or aggregates, and anything whose task bill is large, is a candidate to move. The test is not whether it can be rebuilt, it is whether the rebuild is better.
- 03
Export what Zapier holds
Zap history, which Zapier keeps for a limited period that depends on the plan and lets you export as CSV or JSON, plus held or errored runs, anything stored in Zapier's storage or tables, and digest contents. None of it comes across to Make, so take what you need to keep before you switch anything off. On Team and Enterprise plans you can also export the Zap definitions as JSON, as a record of what each Zap did; Make cannot import that file.
- 04
Rebuild the costliest and most branching first
These are where Make's model pays back, and they teach you the conventions the rest will follow. Build the scenario with writes pointed at a sandbox or switched to log-only.
- 05
Run in shadow against live triggers
Let the scenario receive real events and record what it would have done, then compare with what the Zap actually did. Differences in a date format or a missing field show up here, not in front of a customer.
- 06
Cut over at a recorded moment, then wait
Turn the Zap off and the scenario on at a boundary you note down, set the scenario's starting point to match, and leave the Zap paused, not deleted, for a full billing cycle. Watch the first runs by hand.
What each Zapier idea becomes in Make
Most things map. A few do not, and those are the ones that decide whether a migration is worth doing.
| In Zapier | In Make | Watch for |
|---|---|---|
| Instant trigger | An instant trigger or custom webhook. | The source app's webhook URL changes. If a third party owns the webhook setup, allow for how quickly it can be edited. |
| Polling trigger | A watch module with a schedule. | Set where it starts. Starting from all records replays history; starting from now can skip anything created during the gap. |
| Filter | A filter on the link between two modules. | Filters are conditions set on the link between two modules, not modules of their own, so they are configured on the connector and not dropped onto the canvas. |
| Paths | A router with filtered routes and a fallback. | Both tools can have a fallback: a Paths fallback branch in Zapier, a fallback route in Make. Check whether the Zap used one, because anything that matches no branch is otherwise dropped without an error. |
| Formatter | Functions inside field mappings. | Date formats and timezones may differ. Test with dates near midnight and across a daylight-saving change. |
| Looping by Zapier | An iterator, usually followed by an aggregator. | This is the biggest improvement. Aggregate before writing, so the work happens once per run, not once per row. |
| Delay | A sleep module, or a scheduled scenario. | Short sleeps hold an execution open. For long waits, store the item and process it on a schedule. |
| Storage, tables, digest | A data store and an aggregator. | Contents do not transfer. Export and reload them, and rebuild the digest logic explicitly. |
| Code step | A code module where the plan includes one, or an HTTP call to a small function. | Check plan availability first. Untested code written inside a tool is worth moving into something reviewable anyway. |
| Zapier-only app | The HTTP module or the app's API-call module. | If neither can reach the endpoint, the Zap stays. Check the specific operation exists, not just the app. |
Tasks and credits are not the same unit
Zapier counts tasks: successful action steps. Triggers, polls, filters, Paths, Formatter and Delay steps are not counted. Make bills in credits, which replaced operations in 2025, and for most modules one module run is one credit, including the trigger and a scheduled run that finds nothing; some AI and code modules use more, and routers use none. Check both vendors' current definitions before converting anything.
| Pattern | Zapier | Make | What it means |
|---|---|---|---|
| Instant trigger, three actions, 1,000 runs a month | About 3,000 tasks. | About 4,000 credits. | A straight port of a linear Zap uses a third more units, so it saves money only if the unit price on your plan is lower. |
| Polling trigger on a quiet source, 15-minute interval | No tasks for checks that find nothing. | 96 checks a day, so about 2,900 credits a month before any work. | Move to an instant trigger where the source offers one, or lengthen the interval. Do not port a quiet polling Zap as it stands. |
| Loop over 20 rows, two writes per row | About 40 tasks per run: the loop step is free, and each action after it counts once per iteration. | About 41 credits for the loop if written per row (40 writes plus the iterator), plus the trigger; fewer if the target accepts a batch. | The saving, where there is one, comes from restructuring the loop. It is not from the platform. |
What goes wrong with Zapier to Make
The patterns that turn up on this pair specifically, and what we do about each one.
- 01
Both versions live at once
The classic migration error: the scenario is switched on while the Zap is still running, and every customer gets two emails and two invoices. Run the new one in log-only mode until the outputs match, then switch over at a recorded moment, with the Zap paused in the same sitting.
- 02
A gap or a replay at the cutover
Polling triggers keep a bookmark. Zapier's belongs to the Zap, and Make's scenario starts with its own. Choose a start point that is neither too early, which replays history, nor too late, which skips what arrived in between, and verify by counting records on both sides for the window.
- 03
Deduplication memory that does not travel
A polling Zap remembers what it has already seen, and that memory stays behind. Anything depending on it, such as not re-processing an old record that gets edited, needs an explicit check in the scenario: a stored key, or a status field the scenario sets.
- 04
Credentials that belonged to a person
Many Zaps run on a personal connection. Make needs its own, with the scopes the scenario uses, and the owner is whoever authorises it. This is the moment to move to a shared service account where the app allows it, and to find out which Zaps would have stopped working when their owner left.
- 05
Timezones and formats that shift quietly
A date formatted in one tool's default timezone and read in another's appears a day out for part of the day. Nothing errors. Test the boundaries, and set the timezone on the scenario deliberately.
- 06
Held and errored runs left behind
Runs held because the account reached its task limit, and runs that errored or halted, have not been processed. Replay or resolve them before the switch, or they quietly never happen on either platform.
- 07
Cost surprises from polling
A migration that increases the bill usually has a scheduled trigger on a quiet source or a straight port of a many-step Zap. Both are visible in the cost table before the rebuild starts, which is why the inventory records task use per Zap.
A lead-intake Zap with Paths and a loop, ported and improved
The set-up
Illustrative, not a client result. A form submission triggers a Zap that splits the name, looks the person up in a spreadsheet, takes one of two paths (existing or new), creates a CRM contact, then loops over six selected services creating a task for each, and posts a Slack message per task.
What it comes to
About fourteen tasks per submission on Zapier (the lookup, the CRM write, six task creations and six Slack posts; the Formatter, Paths and loop steps are not counted), against about twelve credits on Make (the trigger, the lookup, the CRM write, the iterator, six task creations, the aggregator and one Slack post; the router uses none). That is a small saving, and nearly all of it comes from one Slack message replacing six. The better reasons to move it are correctness: a fallback route, a single notification, and a scenario whose logic can be exported and version-controlled. If cost were the only reason, this Zap could reasonably have stayed where it was.
- 01
Webhook trigger replaces the form app's Zap trigger
The form tool's webhook is repointed at a Make custom webhook, and the Zap is paused in the same sitting.
- 02
Router replaces Paths, with a fallback
Existing and new become two routes, and a third catches submissions with no email address, which the original silently dropped.
- 03
Iterator and aggregator replace the loop
Tasks are created per service, then an aggregator builds one Slack message listing all six, instead of six messages.
- 04
Shadow run against live submissions
The scenario logs what it would create for a week. The comparison turns up a date shifted by one day near midnight, fixed before cutover.
When not to migrate at all
Leave simple, linear, low-volume Zaps where they are. A non-technical owner who can build, read and fix a Zap unaided is worth more than a few credits saved, and moving it usually costs more in lost self-sufficiency than it recovers. The Zapier platform page makes the same argument.
Do not migrate to save money without doing the arithmetic. If the bill is high because of polling, the first fix is an instant trigger on Zapier. If it is high because of volume and step count, Make may help only modestly, and n8n self-hosted, or running exported Make blueprints on your own infrastructure with an engine such as our Blueprint Runner (which implements a subset of Make's modules), may suit better. The platform comparison article sets out which unit each bills.
Keep anything that uses a Zapier-only app, or depends on Zapier's own products such as its tables and interfaces. And do not migrate at quarter end, during a launch, or when the person who understands the Zaps is about to be unavailable.
Projects that did not use Zapier to Make
Here for the argument rather than as evidence of this integration. Each one bears on a point above, and the note says which.
- A fleet-telematics providerOrders that file themselves, and an SLA clock that never forgetsNot a Zapier migration. It shipped behind a shadow-mode flag and a go-live cutoff, running alongside the manual process and logging what it would have done. That is the same cutover discipline described above, applied to a different change.Case study
- Blueprint RunnerBlueprint Runner: a self-hosted engine that speaks Make nativelyNot a Zapier build. It is relevant to the destination: a Make scenario exports as a blueprint, which is JSON, and Blueprint Runner executes that JSON on your own infrastructure for the modules it implements, so a later move off per-credit billing can be less of a rebuild than this one. A Zapier export is a file for other Zapier accounts, not a portable artefact.Case study
The disciplines behind it
Related reading
Rate limits, plan tiers and which modules exist change over time. Where this page gives a figure it shows how it was derived; for everything else, confirm against the vendors’ current documentation before sizing a build. Skofi holds no partnership, certification or reseller arrangement with any vendor named here.
Zapier to Make, specifically
No. Zapier can export Zap definitions as JSON on its Team and Enterprise plans, but that is for backup and other Zapier accounts, and Make does not import it. A migration is a rebuild from a description of what each Zap does, which is why the audit comes first. It is also why Make blueprints are worth keeping in version control: they are a readable record of every scenario.
Sometimes, and not by default. The two count different things: successful action tasks on one side, credits (formerly operations) that include the trigger and empty scheduled runs on the other. Automations that loop or reshape data often cost less on Make once restructured, while a straight port of a linear Zap can cost more. We estimate from your run history before recommending a move.
Less time goes on building than on the audit and the parallel run. The rebuild of a simple Zap is quick; deciding what to move, exporting what Zapier holds, and watching the shadow run until the outputs match is where the calendar goes. It scales with the number of Zaps that carry real consequences, not with the total count.
Yes, and many teams should. Put each process on exactly one platform. Running the same process on both is how two systems of record start disagreeing, and during a migration it is how customers get double messages.
Check the specific operation first, since an app can have a module that cannot do the thing you need. Where there is none, the HTTP module or an app's API-call module often reaches the endpoint with the same credentials. If it genuinely cannot be reached, that Zap stays on Zapier.
There should be none if the sequence is right: the scenario is built and proven in shadow, then the Zap is paused and the scenario switched on in the same sitting, with a start point chosen to avoid both a gap and a replay. For webhook-driven flows the only moment of risk is repointing the source, which is worth doing outside peak hours.
Sources
Statements about what a platform, regulator or provider says come from their own pages. Rules and limits change, so check the current page before you rely on one.
- Import and export Zap workflows in your Team or Enterprise account · Zapier (Help Center)
- How is task usage measured in Zapier? · Zapier (Help Center)
- Understanding Looping by Zapier · Zapier (Help Center)
- How Zapier handles duplicate data in Zap workflows · Zapier (Help Center)
- Credits · Make (Help Center)
- Select the first bundle to process · Make (Help Center)
Page copy drafted with AI assistance. Skofi is accountable for it. Editorial policy
Tell us about the process that keeps costing you.
A 15-minute call is usually enough to say whether this is an automation, an integration, or something that should be built, and whether we are the right people for it.
What happens on the call
- 15 minutes, no deck
- We map the process on the call
- A written scope, or an honest no