Home › Risk & rules

What Automation Platforms Let You Take With You

Zapier, Make, n8n and Power Automate all publish what you can export and how long they keep your run history. Here is what their own documentation says, and the exit plan to run before you sign.

The Bot Desk staff · September 9, 2026 · 8 min read

Every buying guide warns about vendor lock-in, then moves on. Almost none check what a given platform actually lets you take with you. The check is possible: Zapier, Make, n8n and Microsoft all publish documentation on exports, retention and non-payment. Read it before you sign and lock-in stops being a fear and becomes a number you can budget.

What follows comes only from the vendors' own help centers, API references and license files, each linked. Where a vendor publishes no answer, that is stated as "not documented." The conclusion up front: all four will give you a machine-readable copy of your workflow logic, none will give you your credentials, and the export format is useless to a competing platform anyway. The cost of leaving is rebuilding, not exporting.

What "export" means on each platform

Zapier documents two paths. Zap import and export is a Team and Enterprise feature: "Import and export only support the JSON file format" (Zapier Help Center). Separately, the account data export produces a ZIP containing "Zapfile.json: contains an export of all undeleted Zap workflows, focusing on the data needed to run each Zap" (Zapier Help Center). The supported export sits behind a paid tier.

Make exports a scenario as a blueprint JSON file, and the help page names the gap: blueprints "include modules, settings, and mapped values," but "users still need to create connections for their accounts after importing the blueprint" (Make Help Center). The same file comes from GET /scenarios/{scenarioId}/blueprint; the versions endpoint, GET /scenarios/{scenarioId}/blueprints, is where Make's API reference notes that versions older than 60 days are archived and unretrievable through the API (Make Developer Hub).

n8n is the most open of the four. Workflows are JSON, downloadable from the editor, CLI or public API (n8n Docs), and the API covers workflows, executions, credentials, users, audit, tags, source control, variables and projects (n8n Docs). The docs caution that "exported workflow JSON files include credential names and IDs" — strip those before sharing.

Power Automate has two mechanisms, not interchangeable. A single flow exports as a package: "Export and import packages have the file format *.zip*," and "when you export a flow, the dependent resources for your flow are also exported into the package" (Microsoft Learn). Microsoft points serious customers at solutions, where "each exported workflow is represented as a JSON file" inside the zip — and warns that "you can't export managed solutions" (Microsoft Learn). If a partner delivered your flows as a managed solution, that route is closed.

What you want out	Zapier	Make	n8n	Power Automate
Workflow logic	JSON; import/export on Team and Enterprise. Account-data ZIP includes Zapfile.json; plan eligibility not documented (src)	Blueprint JSON, UI or API; versions over 60 days archived, unretrievable (src)	JSON via editor, CLI and API (src)	.zip package, or JSON per flow in an unmanaged solution; managed solutions cannot be exported (src)
Run history	CSV or JSON, emailed, "up to 5,000 Zap runs at a time" (src)	CSV from the history tab: status, timestamp, author, operations, duration (src)	An API resource (src); no bulk export documented	No bulk export documented; run data can be stored in Dataverse instead (src)
History retention	"Zapier will retain Zap history for 29-69 days"; Enterprise can shorten to 7-30 days (src)	7 days on Free; 30 on Core, Pro and Teams; 60 on Enterprise (src)	Cloud: 7 days Starter, 30 Pro, unlimited Enterprise (src). Self-hosted default 336 hours (src)	30-day run retention (src); Dataverse copy defaults to 28 days, settable to 14, 7 or disabled (src)
Data the platform stores for you	Tables download to CSV on all plans, capped at 50MB; excludes hidden fields and filtered rows (src)	No download documented on the data stores help page (src); data store endpoints exist in the API (src)	An API resource (src); self-hosting also gives you the database	Dataverse export via dataflows, Data Factory, Power Query, Azure Synapse Link (src)
Credentials	Not exportable	Not exportable; connections recreated after import (src)	API: "Credential data (secrets) is not included" (src). Self-hosted CLI exports decrypted (src)	Connection references travel in the solution; the credentials behind them do not (src)
Downgrade or overage	"Zapier will hold all actions for all Zap workflows in your account if you reach your task limit"; premium-feature actions held on lower plans (src)	"Any active scenarios using features of higher plans will be stopped" (src)	No plan-downgrade policy documented	A flow not triggered in 90 days "might be turned off"; continuous failures or throttling, 14 days (src)

Retention is the quiet part of lock-in

Run history is the part people forget. It is the audit trail — who was invoiced, which ticket went where, what the bot did on the day a customer disputes something — and it expires on the vendor's clock. Zapier: "Zapier will retain Zap history for 29-69 days." Make: 7 days on Free, 30 on Core, Pro and Teams, 60 on Enterprise. Microsoft: 30-day run retention, plus a Dataverse copy where "by default, flow run data is stored for 28 days (2,419,200 seconds)."

None of these numbers change when you leave. Cancel in March and the history you did not export in January is already gone. Retention is not a departure penalty — it is a standing condition you have been under the whole time. The only fix is a scheduled export while you are still a customer.

Credentials never come with you

The most underestimated line in any migration estimate. Every OAuth token, API key and app password stays put. Make says it directly: after importing a blueprint, "users still need to create connections for their accounts." n8n's API documentation states that "Credential data (secrets) is not included" in credential reads, and marks that field write-only (n8n Docs).

The one exception is self-hosted n8n, where the CLI offers n8n export:credentials --all --decrypted, with the docs warning that "all sensitive information is visible in the files" (n8n Docs). A capability no SaaS platform offers, and a hazard: that file is the highest-value one you own.

Budget the reconnection work: every connector is another round of logins, consent screens and admin approvals.

The n8n license question, stated precisely

n8n is often called open source. It is not, in the OSI sense, and the vendor does not claim it is. The main branch falls under the Sustainable Use License v1.0, which grants a broad copyright license, then limits it: "You may use or modify the software only for your own internal business purposes or for non-commercial or personal use. You may distribute the software or provide it to others only if you do so free of charge for non-commercial purposes." The same file goes further: files with ".ee." in the filename or ".ee" in the directory are not under that license at all and require an n8n Enterprise License (LICENSE.md). The umbrella term is fair-code, and faircode.io is unambiguous that "fair-code is not a software license" — it describes software free to use with source openly available but "commercially restricted by its authors" (faircode.io).

For a buyer that means something narrow and useful. You can run n8n yourself, read the code, modify it, and keep running it if pricing changes tomorrow — which blunts the sharpest edge of lock-in. You cannot resell it as a hosted service, and enterprise-flagged features are not yours by default.

What a migration actually consists of

Here is the part the abstract warnings skip. Suppose you hold a perfect JSON export of a Zap and want it on Make. There is no path on which it runs, and the reason is not encryption but structure: a Zap describes Zapier's connectors, field mappings and error semantics (held runs, replays, task counting) while a Make scenario describes modules, routers, iterators and error handler routes. There is no lossless mapping: the execution models are different products.

A migration is not a file conversion. It is: inventory every automation and mark which still do real work; document the survivors' business logic, exception branches included; rebuild each in the new platform's idioms; reconnect every credential, which means chasing whoever owns each SaaS admin account; test with real payloads, because field names and date formats will not match; run both in parallel with the old system's writes disabled; then cut over and archive your exports.

Cost that in labor hours. The Bureau of Labor Statistics puts total employer compensation for private industry workers in establishments of 1 to 49 workers at $37.36 per hour as of March 2026 (BLS, Employer Costs for Employee Compensation, Table 6). The hours below are placeholders, not benchmarks; use your own. Twenty automations at 4 hours each to rebuild and test is 80 hours: 80 × $37.36 = $2,988.80. Fifteen connections at half an hour to reauthorize: 7.5 × $37.36 = $280.20. Ten hours supervising a parallel run: $373.60. Total $3,642.60, plus what you pay both vendors during the overlap. What moves that number most is not the platform, but whether anyone can still say what the automations are supposed to do.

The exit plan to run before you sign

Confirm which plan tier unlocks workflow export and price that tier, not the one you were quoted. Take one export of each kind on a trial account and open the files. Read the retention number for the plan you are buying and decide whether it meets your record-keeping obligations; the vendor's default is not built around yours.

Set a monthly recurring export of three things: workflow definitions, run history, and any data the platform holds for you — Zapier Tables, Make data stores, Dataverse tables. Store them where you control. On n8n and Make this runs through their APIs; Zapier's history export is manual, capped at 5,000 runs per pull. Keep a credential register outside the platform: for each connection, the SaaS account it uses, who administers it, and what scope it holds. Ask the vendor in writing what happens to your definitions and history after cancellation, how long backups persist, and whether export stays available during a suspension for non-payment. Keep the answer.

The mitigation that actually works

Exports are necessary and insufficient. What genuinely lowers switching cost is a written description of each automation's business logic, kept outside the platform in a document you own. Not a screenshot of the canvas — a plain-language spec: what triggers it, what decisions it makes and on what conditions, what it writes and where, what happens when it fails, who gets told, and why it exists. Ten lines per automation.

It is the only artifact that survives a platform change, because it is the only one not written in a vendor's vocabulary. A JSON export tells you which modules were wired together. It does not tell you that the second filter exists because one customer's invoices bypass approval, or that a delay is 26 hours because of a downstream batch job. That knowledge makes a rebuild a rebuild instead of an archaeology project, and creating it is entirely within your control.

Price it, don't fear it

Lock-in is not a reason to avoid these platforms. The value is real, and bespoke integration code carries switching costs of its own, usually worse. Every useful tool creates a dependency; that is what adoption means. What is unreasonable is signing without knowing the number. Spend an hour on the export documentation, take the trial exports, write the ten-line specs, schedule the monthly backup, and the dependency becomes a line item you can manage. The buyers who get hurt are not those who chose a platform with lock-in, but those who never checked what leaving would cost until they had to.