Switching from Make to Zapier — when the rebuild is worth it

Expect a rebuild, not a file drop. In Make, everything you build is a scenario, and modules are the building blocks. A standard scenario follows fixed rules. The first module is the trigger. Later modules run in sequence. A blueprint is a reusable copy of that scenario: scenario modules, module settings, and mapped values. You export it from the Scenario Builder as a .json file, or copy the JSON to the clipboard. Import is the same file, back into Make. The imported blueprint must stay below 2 MB. After import, the help article tells you to create your own connections, edit the scenario, schedule it, and save. That path moves a scenario inside Make. It does not create a Zap.

A Zap is a trigger plus one or more actions. Zapier’s import-and-export article covers backing up and sharing Zap workflows with other Zapier accounts as JSON, from Settings, then Security and data. Import is not available during your free Zapier trial. After import, the article tells you to turn the Zap workflows on and test app connections. If a connection is no longer active, reconnect it. That path moves a Zap inside Zapier. It does not read a Make blueprint.

So the expectation is: one scenario becomes one Zap you build. The trigger module becomes the trigger step. Each later module becomes an action, or a step you rebuild by hand. Fields are mapped again. Do not assume a Make router, filter, or data-store module lands as the same step. The two JSON files are not interchangeable.

Source: Make — what’s a scenario · Make — blueprints · Zapier — what is a Zap · Zapier — import and export Zap workflows · accessed 2026-10-12

Make says users still need to create connections after importing a blueprint. You create a connection in the Scenario Builder when you add a module. The steps vary by app: a login, or a username, API key, client id, and client secret. If Make does not offer an integration, the HTTP app is Make’s path. Manage connections under Credentials. All users in that Make team can use the connections created there. Editing a connection replaces the stored details: Make does not keep the original connection data, so you enter the credentials again. None of that fills a Zapier app connection.

On Zapier you connect the account in the Zap, from the App connections page. You can test a connection, reconnect an expired one, or replace it with a different account. Zapier’s connection export never includes credentials, API keys, or other sensitive authentication data. It is metadata only. After a Zap JSON import, the import article tells you to test app connections and reconnect any that are no longer active. That reconnect is still a Zapier connection. It is not a filled Make connection.

Plan the overlap around that fact. Name who will create each Zapier connection and who still owns the Make connection until the scenario is off. A scenario that still runs is not a Zapier app connection.

Source: Make — blueprints · Make — connect an application · Zapier — export app connections · Zapier — manage your app connections · Zapier — import and export Zap workflows · accessed 2026-10-12

Make webhooks create a URL that an external app, or another scenario, can call. Custom webhooks use Make’s Webhooks app. Some webhook detail views include a Webhook URL. That URL does not become a Zapier URL. A Catch Hook trigger gives you a unique URL. You copy it from the Zap’s Test tab and paste it into the sending app. The trigger article says that URL only changes if the Zap is transferred to another user, because the URL contains the owner’s Zapier ID. If the Zap is turned off or deleted, Zapier returns a 404 for incoming requests after a system update delay of up to several hours, during which the URL can still return 200. If senders POST to the Make URL, point them at the new Zapier URL before you rely on the new job. Do not leave both URLs writing the same row. Make deactivates a webhook that is not connected to any scenario for more than 5 days (120 hours) and then returns 410 Gone. Keep the Make scenario connected during the overlap.

The pricing page lists Connections via webhooks on Professional, Team, and Enterprise, and leaves that row off Free. The trigger-from-webhooks article’s plan badges match that row: Free is ineligible, and Professional, Team, and Enterprise are eligible.

A Data store is a Make tool. The types-of-modules article lists it with tools that do not use a third-party connection, and says a Data store may ask you to create the store inside Make. The blueprint article lists scenario modules, module settings, and mapped values. It does not list data-store records. The pricing FAQ says an organization can use up to 1,000 data stores regardless of plan, that the minimum size of one data store is 1 MB, and that the Free plan’s 1,000 credits equal 1 MB of data storage and 1 data store. The pricing page names Zapier Tables as a database tool on Zapier. A Make data store is not a Zapier Table. The records stay in Make unless you copy them yourself into a store the new Zap can read.

A schedule is set in Make’s Schedule settings. An instant trigger sets the scenario to run as soon as data arrives, and you can reschedule it. After you import a blueprint in Make, the help article tells you to schedule the scenario and save. The developer Get scenario blueprint response can include a scheduling object. The type values on that object include immediately, indefinitely, once, daily, weekly, monthly, and yearly. That object is still Make’s schedule. It is not Schedule by Zapier. Schedule by Zapier is set in the Zap editor. You can run the Zap every month, week, day, or hour, or on a custom frequency. Using that tool does not count toward task usage. Zapier does not guarantee the Zap will trigger at the precise minute you set. The timezone is the one on the Zapier account, not the Make schedule. Set the schedule again on the Zap. The Make export does not carry a live sender over, and a Zapier JSON file does not read the Make URL.

The rest of what sticks — history, one-tool steps, permissions, leftover quota — is on What does not migrate. This page does not reprint that list.

Source: Make — webhooks · Zapier — trigger Zap workflows from webhooks · Zapier — pricing · Make — types of modules · Make — blueprints · Make — pricing · Make developer — scenario blueprints · Zapier — schedule Zap workflows · accessed 2026-10-12

The parallel-run period is one critical job, not the whole account. Keep that scenario on. Rebuild it as one Zap. Create the Zapier connections. If the job has a webhook, re-point the sender for the window you are comparing, and do not let both copies write the same live row. Compare the writes for the same trigger window — the row, the message, and what happens when a required field is missing. Then turn that scenario off. Leave the scenario intact until the Zap has handled a real run, so you can turn the Zap off and leave the scenario on if the writes do not match.

An editor test is not that proof. Zapier says a Zap only processes new data created after it is published. Test records are sample data used while building and may differ from the data the Zap receives during live runs. Compare a published window, not only an editor test.

Do not move every scenario on the same day. Make and Zapier do not publish a required number of days for that overlap. This page does not invent a required number of days. The checklist — which job, what to compare, how to go back — is Parallel-run one job before you switch.

Scenario history does not shorten that period. Make keeps scenario history on the History tab: run date and time, status, duration, operations, credits consumed, and the details of that run. You can export the tab as CSV. The file includes execution status, timestamp, author, operations count, execution duration, and a link to the execution. How many days those entries stay depends on the plan. That file is history. It is not a Zap, and it does not become Zap history. Zapier can export up to 5,000 Zap runs at a time, as CSV or JSON, and email that file to the Zapier account. That list stays on the tool where it ran.

Source: Make — scenario history · Make — webhooks · Zapier — what is a Zap · Zapier — export your Zap history · accessed 2026-10-12

Credits are what you buy and consume to use Make. For non-AI apps, 1 operation equals 1 credit by default. Some modules use more than that default. The pricing FAQ says most actions consume 1 credit, and that error-handler modules and the Router module do not count. A scenario can use anywhere from two credits to thousands of credits in a single run. A task is any successful action that runs in Zapier. Only successful actions count. Triggers do not count. Filter and Paths steps do not count. In Zapier’s own example, a Zap that uploads a file and sends a message uses two tasks each time both actions succeed. Ten runs use 20 tasks. One credit is not one task. Leftover Make credits do not become Zapier tasks.

If Make credits run out, scenarios do not continue until credits are added again. Incoming webhooks queue up to the webhook queue storage on the plan, then process once credits return. That queue is still Make. It is not a Zapier task balance. If a Zapier plan does not include pay-per-task billing, or you have turned it off, Zapier holds new Zap runs once the plan reaches its task limit, until the billing cycle resets. The pricing page lists pay-per-task billing on Professional, Team, and Enterprise, and not on Free. This page does not copy a per-task rate.

Name the same job in both units before you treat a switch as a smaller bill. The dictionary is Tasks vs credits vs executions. The Make credit map is Make credits and operations and Make pricing explained. The Zapier task map is Zapier pricing explained. This page does not claim you will save. It publishes no annual savings. It does not invent a monthly dollar.

Source: Make — credits · Make — pricing · Zapier — how task usage is measured · Zapier — pricing · accessed 2026-10-12

Primary vendor pages. Access date for every citation on this page: 2026-10-12. Plan names stay as published. Dollar bills stay off this page.

• Make — what’s a scenario · accessed 2026-10-12
• Make — blueprints · accessed 2026-10-12
• Make — connect an application · accessed 2026-10-12
• Make — credits · accessed 2026-10-12
• Make — scenario history · accessed 2026-10-12
• Make — webhooks · accessed 2026-10-12
• Make — types of modules · accessed 2026-10-12
• Make — pricing · accessed 2026-10-12
• Make — change your subscription · accessed 2026-10-12
• Make developer — scenario blueprints · accessed 2026-10-12
• Zapier — what is a Zap · accessed 2026-10-12
• Zapier — import and export Zap workflows · accessed 2026-10-12
• Zapier — export app connections · accessed 2026-10-12
• Zapier — export your Zap history · accessed 2026-10-12
• Zapier — how task usage is measured · accessed 2026-10-12
• Zapier — manage your app connections · accessed 2026-10-12
• Zapier — trigger Zap workflows from webhooks · accessed 2026-10-12
• Zapier — schedule Zap workflows · accessed 2026-10-12
• Zapier — pricing · accessed 2026-10-12