Migration
Zapier to Make.com migration service
Leaving Zapier for Make is the move for teams who want a cheaper meter and real branching without taking on a server. Nothing imports: every Zap is rebuilt as a scenario, with Paths becoming routers, Formatter steps becoming inline functions, and every silent failure turned into an error path somebody actually chose.
The mapping
What does a Zap become once it is a scenario?
It becomes a canvas rather than a list. A Zap is an ordered stack of steps, and every piece of shaping logic — filtering, formatting, looping — has to be its own step in that stack. Make draws the same work as connected modules, and a good deal of the shaping stops being a step and becomes a property of the connection between two of them.
That one structural difference is why a migration is a rebuild and not a transfer. There is no export from Zapier that Make can read, and no converter worth trusting, so the honest starting point is an inventory: every Zap, every step, every field mapping, every filter condition, with the owner and the last successful run beside it. That inventory reliably turns up the same three things — a Zap nobody remembers creating, two Zaps that are the same Zap with one field changed, and a Path branch that has never once fired.
What does not survive the move untouched is Zapier's failure behaviour. On Zapier a broken run lands in the error queue and, on paid plans, may be replayed for you; the practical effect is that nobody had to decide what a failure means. Make asks that question directly, because an error handler is attached to a module and carries an explicit directive — break it for a later retry, resume with a fallback value, ignore it, or roll the whole run back. Answering that per integration is more work than translating steps, and it is the part of the project worth paying for, because the answers were never written down on the Zapier side either.
| In Zapier today | What it is doing | Where it lands in Make |
|---|---|---|
| Zap | One trigger and an ordered list of action steps | A scenario: the same trigger and steps drawn as connected modules, and exportable as a blueprint file you can keep |
| Trigger | Starts the run, either on a polling interval Zapier controls or instantly from a webhook | A trigger module — instant where the app offers a webhook, scheduled where it does not, with the schedule yours to set |
| Action step | One operation in one connected app | A module, joined by a line that carries the bundle onward |
| Paths | Named conditional branches, each with its own steps | A router with a filter on every route, plus a fallback route so nothing falls out of the scenario unnoticed |
| Filter by Zapier | A step whose only job is to halt runs that do not qualify | Not a step: a filter set on the line between two modules, with the condition visible on the canvas |
| Formatter by Zapier | Text, date, number and utility transforms, one step each | Functions written inline in the mapping panel, so most Formatter steps stop existing as steps |
| Looping by Zapier | Repeating the steps below once per item in a list | An iterator to split the list, and usually an aggregator to fold the results back into one bundle |
| Code by Zapier | Arbitrary Python or JavaScript embedded in the Zap | No like-for-like module: simple cases become functions, and genuinely custom logic moves to an HTTP call against an endpoint you own |
| Storage by Zapier | A small key-value store holding state between runs | A data store — named structures with typed columns, readable and writable from any scenario in the team |
| Autoreplay and the error queue | Failed runs held for retry, with the retry decided by the platform | An error handler on the module with a directive you choose: break, resume, ignore or rollback |
| Connected account | A stored authorisation to act inside a CRM, mailbox or ledger | A connection, re-authorised at least privilege rather than migrated |
| Tasks | Billed per action step that runs successfully | Operations, billed per module call — a smaller unit counted over a different set of steps, so the two totals are not comparable by arithmetic alone |
Read both meters before deciding. What Make counts as a consumed operation is set out in Make's own help pages (opens in new window), and what Zapier counts as a task is defined in Zapier's help centre (opens in new window). Connections are the part of any migration that deserves the most care — every one is re-issued, which is the moment to scope it properly and give it an owner who is not somebody's personal account. We handle that side against the NIST Cybersecurity Framework (opens in new window).
The trigger
Why the task meter is usually what starts this
Teams rarely leave because the builder is bad — Zapier's is the easiest of the three to hand to a non-technical colleague. They leave because a task is charged per action step, so the automations that became most valuable are the ones costing most: the Formatter steps that only reshape a date, the Filter step that runs before the work does, the loop that turns one order into forty. None of that is waste in the sense of being pointless. It is just billed, and the bill grows with the business rather than with the value of the automation.
Make changes the unit rather than removing it. Operations are smaller and plans carry far more of them, and several of the things that cost a task on Zapier — filtering, formatting, branching — cost nothing on the Make side because they are not modules. Against that, iterators and aggregators are modules and do consume operations. Which way a given workflow lands depends on its shape, not on the headline tiers, so we model your real run history before recommending the move at all.
There is a second reason worth naming, because among the teams we talk to it decides as many migrations as cost does: branching. Zapier's Paths are capped and awkward to nest, and a process with genuine decision logic tends to get split across several Zaps chained by webhooks — at which point no single screen shows what the process does. A router on a canvas shows it. That is a maintainability argument, and it survives long after the invoice stops being the reason.
What Make does not give you is anywhere else to run it. The platform hosts your scenarios and holds your data, exactly as Zapier does. If the real requirement is self-hosting, data residency, or removing the meter altogether, then Make is the wrong destination and the question is a different one — which is what the two n8n routes below are for.
Sequence
How the move runs, stage by stage
Inventory and triage
Every Zap read and recorded: steps, mapped fields, filter conditions, owner, last successful run, tasks consumed. Duplicates get consolidated and dead Zaps get retired, because paying to rebuild waste is still paying for waste.
Rebuild on the canvas
Each surviving Zap rebuilt as a scenario rather than transliterated — Paths expressed as routed branches, Formatter steps folded into functions, and an error handler chosen for every module that touches a third-party API.
Parallel run
Both versions fire on the same real triggers with the scenario's write modules disabled, until the outputs agree. Where they disagree is where the undocumented logic was hiding.
Cutover, one Zap at a time
Cutover happens per automation, never as one event. The scenario takes the trigger, the Zap is switched off but kept, and the Zapier plan stays live through a quiet period before anything is deleted or downgraded. Cancelling early is the only irreversible step in the project, and it saves a fraction of what an unplanned rollback costs.
You finish owning the result outright: scenarios exported as blueprints, connections issued in your own accounts, data stores documented, and a runbook naming what each error path means and who gets alerted when it fires. If your team would rather run the rebuild themselves, we set up the conventions and the first few scenarios and stay on as backup.
Where this sits next to the rest of the work
Leaving is not the only option and it is not always the right one. If the Zaps are sound and the bill is tolerable, hardening what you have is cheaper — that is what Zapier automation consulting covers, including the task economics and the silent-failure patterns that make a Zap survivable without moving it anywhere. Once you have landed on the other side, a Make.com automation consultant covers the scenario work, operations budget and error handling that follow.
If the destination is still open, the comparison of n8n vs Zapier vs Make argues it on hosting, pricing unit and flexibility rather than on feature lists — read that first if you are not yet sure Make is where you want to end up. The two routes that end somewhere else are worth reading on their own terms: the Zapier to n8n migration is the same starting point for teams who want to self-host and stop being metered at all, and the Make.com to n8n migration is the route out for teams already on Make whose operations bill has become the constraint. This page is the one for teams who want to stay no-code, keep the platform doing the hosting, and change the meter.
Questions
Common questions about moving on to Make
Can our Zaps be imported into Make automatically?
No. There is no import path between the two platforms, and there is no export format on the Zapier side that Make can read. The rebuild is done by hand, one Zap at a time, working from an inventory of every step, field mapping and filter condition. The logic is already proven, which is what makes the rebuild fast rather than speculative.
What happens to Paths, Filters and Formatter steps?
Paths become a router with a filter on each route and a fallback route for anything that matches nothing. A Filter step stops being a step at all: in Make a filter sits on the line between two modules. Most Formatter steps also disappear, because the same text, date and number transforms are written inline as functions in the mapping panel.
Will Make actually cost less to run than Zapier?
Usually, but the two meters are not comparable without modelling your own volumes. Zapier bills a task per action step that runs; Make bills an operation per module call, and the set of steps that count is different. A workflow that fans one record into many can land in very different places under the two schemes, so we model it against your real run history before recommending the move.
How long do we keep paying for both platforms?
Through the parallel run and a quiet period after cutover, which is the only sensible answer. Cancelling the Zapier plan is the one irreversible step in the project, and it saves a fraction of what an unplanned rollback costs. Zaps are turned off rather than deleted, and the account stays live until the scenarios have earned the traffic.
Free consultation
Tell us what is costing you the most time
Describe the process. You get a straight read on whether it is worth automating, roughly what it would take, and what we would tackle first — on a call that costs nothing.
- Under an hour, free, and no obligation
- Fixed price per stage, agreed before any work starts
- You own everything we build, documented and in your accounts
- If you do not need us, we will say so on that call
The form is the fastest way to reach us — we reply from a real person, usually within one business day.
Not sure which migration is right? See the CRM migration services overview.