→

How to Switch from Zapier to Make

This is the most expensive migration on this site, and the reason is simple: nothing transfers. There is no export format, no importer, and no realistic conversion path — every Zap is rebuilt by hand as a Make scenario, and every one of them is a live integration that something in your business currently depends on. The good news is that the rebuild is usually where the savings come from, because a Zap that ran five steps for five tasks often becomes a scenario that does the same work for fewer operations. What sinks these migrations is not difficulty, it's sequencing: people rebuild the interesting automations first, turn off Zapier before the boring ones are done, and find out which invoice never got created. This guide covers the inventory, the order to rebuild in, the billing model change, and the cases where staying on Zapier is simply correct.

Workflow automation⏱ Half a day for a handful of Zaps; a week or more for a real estate of them7-step migration

Why people leave Zapier

🕸️ Branching and loops as first-class structure

A Make scenario is a canvas: routers split the flow, iterators walk arrays, aggregators put them back together. Anything that needed several chained Zaps and a helper spreadsheet on the old side usually collapses into one scenario — that consolidation is the real win, not the price.

💰 Operations pricing that rewards efficient design

Billing counts operations rather than completed tasks, and at volume the same workload typically lands cheaper. It also means design choices affect the bill: filtering early so a module never runs is now a cost decision, not just a tidiness one.

🧯 Error handlers per module

You can attach a defined error route to a module — retry, ignore, or divert to a notification — instead of discovering a silent failure days later. For automations that touch money or customer data, this alone justifies the rebuild.

🔍 Execution history you can actually inspect

Each run is inspectable module by module with the data that passed through it. Debugging a misbehaving automation stops being guesswork, which matters more the more of your operations run unattended.

Stay on Zapier if…

A migration you regret costs more than the subscription you were trying to escape. These are the cases where Zapier is still the right answer.

•One of your critical integrations exists on Zapier and not on Make. Zapier's app catalogue is the largest in the category, and a single missing connector for a system you can't replace ends the migration — check every app in your inventory before you rebuild anything, not after.
•Non-technical colleagues build and maintain their own Zaps. The linear trigger-then-action model is deliberately simple; a canvas with routers and iterators is more capable and genuinely harder. If automation ownership is distributed across a team that isn't technical, moving it centralises maintenance onto whoever runs the migration — usually you.
•Your automations are simple and low-volume. Under a few hundred runs a month with two or three steps each, the price difference is small and the rebuild cost is real. Migrating to save a few pounds a month is a bad trade for a week of work and a period of elevated risk.
•You're mid-quarter on something that depends on these automations running. Do not run this migration during your busiest period. There is no rollback for an order that didn't sync — pick a quiet fortnight.

What you gain and what you give up

Capability	Zapier	Make
Number of app integrations	Largest catalogue in the category	Broad, but smaller
Ease for non-technical builders	Linear and approachable	More capable, steeper
Branching, routing and loops	Possible but awkward	Native canvas primitives
Error handling	Basic retries and alerts	Per-module error routes
Execution debugging	Task history	Module-level run inspection
Cost at high volume	Task-based, rises quickly	Operations-based, usually cheaper
Data transformation	Formatter steps and code steps	Built-in functions plus code modules
Migration effort from the other tool	n/a	Full manual rebuild — nothing imports

Green marks the stronger side of each row. Rows where both are comparable are left neutral.

The migration, step by step

Inventory every live Zap and what it's worth

1–2 hours

List every enabled Zap with its trigger app, its actions, roughly how often it runs, and one line on what breaks if it stops. Sort by that last column. Almost everyone finds a third of the list is dead or duplicated — turning those off is free savings and shrinks the rebuild before it starts.

Check every connector exists on the other side first

45 minutes

Go through the app list from your inventory and confirm each one has a Make module with the specific actions you use — not just an app tile. This is the step that decides whether the migration is possible at all, and finding a gap now costs 45 minutes while finding it in week two costs the rebuild you already did.

Rebuild one medium-complexity scenario end to end

1 hour

Not your simplest and not your most critical — something with a filter and two actions. Building one properly teaches you routers, mapping and the run inspector, and gives you a real number for how long the rest will take. Estimating the project from the docs instead of from one real rebuild is how week-long migrations become month-long ones.

Run both in parallel with the new one writing nowhere

Ongoing during the rebuild

Leave the Zap on. Build the Make scenario alongside it with the final write action disabled or pointed at a test destination, and compare the data flowing through each. Parallel running is what makes this migration safe — it is the only way to catch a field mapped to the wrong place before it lands in your CRM.

Cut over in dependency order, lowest risk first

Spread over days

Switch off each Zap only once its replacement has run clean on live data, and start with the automations at the bottom of your impact list. Anything touching invoices, payments or customer-facing messages goes last, when you've built twenty scenarios and actually know the tool. Never disable a Zap the same hour you enable its replacement.

Optimise for operations before you pick a plan

1 hour

Once everything runs, look at what's consuming operations. Filter early so modules don't execute on records you'll discard, and batch where you can. A scenario rebuilt one-to-one from a Zap is rarely the efficient version, and the difference decides which plan tier you land on — do this before you commit to an annual price.

Keep Zapier alive for one cycle after the last cutover

5 minutes to cancel

Downgrade rather than delete for a month. Monthly and quarterly automations only prove themselves when their trigger date arrives, and that date may be three weeks after you thought you were finished. Cancel once a full cycle has passed with nothing falling over.

What does not come across

Every migration loses something. Budget for these before you cancel Zapier, not after.

✗Every Zap. There is no export or conversion path — this migration is a manual rebuild, and that is the entire cost of it.
✗Task history and run logs on the Zapier side, which disappear with the account. Export anything you need for an audit trail first.
✗Any integration that exists in Zapier's catalogue and not in Make's — verify before you start, not during.
✗The ability for non-technical colleagues to maintain their own automations, in most teams.
✗Zapier-specific features your workflows lean on, such as its built-in tables, interfaces or chatbots, which have no like-for-like replacement.

Zapier → Make: common questions

Can I import my Zaps into Make?

No. There is no export format, no official importer, and no third-party converter that handles real-world Zaps reliably. Every automation is rebuilt by hand, which is why the inventory step matters so much — the honest project estimate is roughly an hour per non-trivial automation once you've done a couple.

Is Make actually cheaper than Zapier?

Usually at volume, because operations-based billing charges for the work done rather than per completed task, and one scenario often replaces a chain of Zaps. At low volume the difference is small enough that the rebuild cost dominates. Model your own numbers from the inventory before committing — and remember an inefficiently rebuilt scenario can cost more, not less.

How long does the migration take?

Half a day for five or six simple automations. A week or more for a real estate of thirty-plus with branching and monthly triggers, because the parallel-running period is measured in calendar time rather than working hours. Budget by the number of automations that touch money, not by the total count.

What's the biggest risk?

Turning off a Zap before its replacement has proven itself on live data. A failed automation is silent — nobody reports the invoice that was never created. Parallel running with the new scenario's final action disabled, then cutting over lowest-impact-first, removes almost all of this risk for the cost of one extra month of overlap.

Should we move everything, or split across both?

Splitting is a legitimate end state, not a failed migration. Complex, high-volume, branching work moves to Make where it's cheaper and more maintainable; a handful of Zaps stay for connectors Make doesn't have, or for automations non-technical colleagues own themselves. Two cheap plans often beat one expensive one plus a rebuild you didn't need.