What you can export from Make and what you cannot
If a renewal, a credit bill or a residency rule is pushing you off Make, the first question is what leaves with you. Scenarios leave as blueprint .json files, but connections and account credentials do not. A blueprint holds a scenario's modules, module settings and mapped values, so it gives your team the structure of each automation to rebuild from. Every connection has to be created again for the account that runs the rebuilt scenario, so plan for a credential step on the new platform for each app a scenario touches.
Make offers three ways to move a blueprint: export a .json file to your device, import a .json file, or copy the blueprint as JSON text to the clipboard. Exported files are named after the scenario, for example name.blueprint.json, which helps when you inventory a large set. Be aware of the import limit: Make cannot save imported blueprints larger than 2 MB, so a very large scenario may need to be split or trimmed before it can be brought back in. Confirm current limits and handling for your plan with Make's blueprint help article before you plan an export batch.
Treat the blueprint as a design document, not a data backup. Records processed by past runs, the run history and any data your scenarios stored outside the blueprint are not part of the file, so export or retain them through your own process if you need them. Ask your team to inventory which scenarios hold mapped secrets or personal data inside their settings, and confirm with Make what your account and plan allow you to retrieve before you decommission anything.
Which Make assets export and in what format
This table lists what a Make blueprint holds, the three ways to move one, and the size limit on imports. Read it to decide which export route fits your rebuild and to see what a blueprint leaves out, such as connections and account credentials.
| Asset or limit | Export method | Format and contents | What to plan for |
|---|---|---|---|
| Scenario structure (modules, module settings, mapped values) | Export to device, copy as JSON text, or import from file | name.blueprint.json, named after the scenario | Use the file as a plan for the rebuild, not as a full copy of the working scenario |
| Connections and account credentials | Not included in any blueprint export | Not present in the JSON | Recreate every connection in the target platform under the owning account |
| Export to device | Save the blueprint as a .json file on your computer | name.blueprint.json | Keep the file in version control or secure storage, since it can reveal logic and mapped values |
| Copy as JSON text | Copy the blueprint as text to the clipboard | Raw JSON text | Useful for pasting into notes or review tools; check that the full text was copied |
| Import from file | Load a .json blueprint into Make | Make blueprint JSON | Imported blueprints larger than 2 MB cannot be saved, so split or trim very large scenarios |
| Other export paths (organization-level, API) | Not described in the supplied blueprint documentation | Unknown from this page | Confirm with Make whether your plan offers organization-wide or API-based export before you plan the migration |
What a blueprint leaves behind and how to rebuild it
A Make blueprint carries the scenario's structure, module settings and mapped values, but it is not a full copy of the account. Connections, run history, data store contents, webhook endpoints and scheduling state sit outside the file, so each needs its own capture step before a rebuild starts.
Connections and account credentials
A blueprint omits connections, so every app login used by a module must be created again after import. Record the connection list before export: note each app, the account it authenticates against, the owner and any OAuth scopes. Use that list as the rebuild checklist and confirm each connection works in the target platform before turning the scenario on.
Data store contents
Records held in Make data stores are not part of the scenario file, so an exported blueprint can rebuild the logic without the data it reads and writes. Export the store contents separately through the Make interface or API, and check the record count and key fields against the source before cutover. Ask Make support to confirm the supported export path for your plan.
Webhook URLs
Webhook endpoints are generated by Make, so a rebuilt scenario in another platform receives a new URL. Every external system that posts to the old address, such as a form tool or payment provider, needs its endpoint changed during cutover. Keep the old scenario active until those senders are repointed, and confirm with Make support how long the old endpoint keeps accepting requests.
Run history and scheduling state
Execution logs, incomplete runs and scheduling state such as next run times are not in the blueprint. Export or screenshot the relevant run history for audit purposes, and note which scenarios run on a schedule and at what interval. Before turning the rebuilt workflow on, make sure the old scenario is deactivated so the same job does not run twice, and check whether any in-flight items need manual handling.
Blueprint size and structure checks
Make cannot save imported blueprints larger than 2 MB, so large scenarios may need to be split before import or rebuilt by hand. Review the exported file for embedded values that should be moved to a secrets store, and check that mapped references still point to the right modules after any restructuring. Test each branch with sample data before going live.
Export sequence for a complete Make scenario inventory
This sequence turns the scattered scenarios in a Make organization into a versioned, checked set of blueprint files and a written record of the connections they depend on. The result is an inventory that a rebuild team can work from without relying on memory or the live Make account.
Inventory every scenario and its owner
List every scenario across all teams and organizations in your Make account, including paused and inactive ones. For each, record the scenario name, the team or folder it sits in, the person who built or maintains it, and whether it is still in use. Ask the owners to confirm which scenarios are production, which are tests, and which can be retired. The step is done when every scenario has one named owner and one status, and nothing is left unassigned.
Export each blueprint as a JSON file
Open each scenario and export it as a blueprint, which Make saves as a .json file named after the scenario, for example name.blueprint.json. Export the file to your device, or copy the blueprint as JSON text to the clipboard if you prefer to save it through a script or document store. Keep the exported filename matched to the scenario name in your inventory so each file maps to one row. The step is done when each inventoried scenario has exactly one blueprint file saved.
Check each file against the 2 MB limit
Measure the size of every exported file and compare it with the 2 MB limit that Make documents for importing blueprints. Flag any file that is over the limit or close to it, because it cannot be imported back into Make as-is. For those scenarios, have the owner review the design and split or simplify the scenario before exporting it again, and note the change in the inventory. The step is done when every file is under the limit or has a recorded plan for its rebuild.
Record every connection and its account
Blueprints do not carry connections or account credentials, so list each connection that each scenario uses. For every connection, record the app, the account or tenant it authenticates against, the Make user or team that owns it, and the scenarios that depend on it. Store this list with the blueprints and mark which connections need a service account or a new credential in the target environment. The step is done when every module in every scenario maps to a recorded connection, and no connection is attributed only to a person who may leave.
Store the files in version control
Commit the blueprint files, the scenario inventory and the connection register to a private Git repository with a clear folder structure, one folder per team or environment. Use commit messages that name the scenario and the export date, and restrict repository access to the people who manage the migration. Review the repository as you would any other configuration, since blueprints contain module settings and mapped values that describe how your business data moves. The step is done when a fresh clone holds the complete inventory and a teammate can find any scenario in a few minutes.
Re-import one blueprint in a test environment
Choose one representative scenario and import its blueprint into a separate test environment, then recreate its connections by hand using the register. This tests whether the file is usable and shows what Make expects to be configured. Confirm the import succeeds before you rely on the export for any other scenario. The step is done when the test scenario opens and its connections are recreated without errors.
Compare module count and mapped values
Compare the re-imported scenario with the original, checking the number of modules, the order and type of each module, the module settings and the mapped values that move data between steps. Use a diff tool on the JSON files where possible, and have the scenario owner sign off on any difference. Any mismatch in module count or mapped values means the export is incomplete for that scenario and must be investigated before the rest of the inventory is treated as reliable. The step is done when the counts match and the owner confirms the mappings.
Why connections and credentials have to be recreated wherever the scenario lands
A blueprint carries the logic of a scenario but not the authorizations behind it. Make's help center states that connections are not included in the exported .json file and must be recreated after import, so every rebuild, whether in n8n, Activepieces or another tool, needs fresh credentials created by the new owner. The module settings and mapped values travel with the file, but the OAuth grants, API keys and tokens that let each step reach Salesforce, Google Sheets or a database do not. Treat the blueprint as a logic document and assume every credential will be issued again from zero.
That gap has a security consequence. The secrets stay bound to the original Make account, and the account owner or administrators there keep control over them. The new platform needs its own secret storage, its own access model and its own rotation process before any scenario goes live. Decide where credentials will be stored (the platform's encrypted credential store or an external secrets manager), who may create and view them, which service accounts will own them and how revocation works when a person leaves. Note that in n8n queue mode the main instance's encryption key must be shared with every worker and webhook processor so they can read stored credentials, so that key becomes a secret in its own right. Confirm the exact storage and key handling for your chosen platform and version in its documentation before cutover, and revoke old Make connections once the replacement is verified.
A practical check before cutover: list every connection each blueprint references, record the account it authenticates against, and assign an owner for each one in the new environment. Scenarios that depend on personal accounts should be moved to service accounts with least-privilege scopes where the target application supports them. This inventory is also the evidence an assessor will ask for when reviewing how third-party access was re-established and who approved it.
What to plan before the Make contract ends
A blueprint export covers scenario logic only, so the rest of the exit depends on decisions made before the contract ends. The cards below cover the timing, ownership, evidence and cutover choices that determine whether the move is controlled or rushed.
Set the export deadline against renewal
Work backward from the contract end date to set an internal date by which every scenario must be exported and reviewed. Confirm with Make, in writing, when access to the account and its scenarios ends and whether exports stay possible after a downgrade or cancellation. Treat that confirmed date as the deadline, not the renewal date itself.
Confirm who holds the owner role
Identify which named people hold the account owner or administrator role, because export and account decisions depend on that access. Make the handover explicit: if an owner leaves during the exit, the team needs a documented way to regain control of the account. Record the account owner in the exit plan and keep at least two administrators with access.
Retain run history and logs for audits
A blueprint holds scenario design, not the execution history that auditors often ask for. Before access ends, decide which run logs, error records and change records your compliance team needs, then export or archive them in a format you control. Ask Make which history is retained after cancellation and for how long before relying on it.
Freeze scenario changes during cutover
Agree a change freeze on each scenario from the moment its blueprint is exported until its replacement is live and verified. Without a freeze, edits made in Make after export will not appear in the rebuilt workflow. Record the blueprint version used for each rebuild so the team can compare the two.
Identify the data residency zone
Make lets an organization pick a US or EU zone for its data, so the zone in use determines where any remaining data is held. Confirm which zone the account was created in and where scenario run data and logs are stored. Keep this record with your data processing documentation, since the zone affects the deletion and transfer conversations with Make.
Verify deletion after exit
After the final export, request written confirmation from Make that account data, including scenarios, logs and stored credentials, has been deleted from its systems. Keep a checklist of every connection that was used, since those credentials must be revoked in the source apps as well. Retain the confirmation with your exit records.
Questions buyers ask before exporting from Make
How much effort does exporting Make scenarios take?
The export itself is quick for each scenario, because Make saves a scenario as a blueprint JSON file in a few clicks. The effort comes from what happens after the file is saved. Each blueprint holds the modules, module settings and mapped values, but not the connections, so every app login has to be recreated in the new environment. Effort rises with three drivers: the number of scenarios, how many modules and routers each one contains, and how many distinct app connections the team must rebuild and test. A small set of simple scenarios with few apps is a short job. A large estate with custom webhooks, error handlers and many accounts is a project in its own right. Ask for a scenario inventory with module counts and connection counts before estimating anything.
Can our team export and rebuild Make scenarios on its own?
Yes, a team with Make and target platform experience can export blueprints and rebuild simple scenarios without outside help. The export tooling is available to users with access to the scenarios, and Make offers three ways to share a blueprint: export a file, import a file, or copy the JSON to the clipboard. Teams usually need help in three places: mapping routers, iterators and aggregators to the new platform's constructs, handling error paths and credentials, and proving that outputs match the original. If your scenarios are few and your engineers have time to test them side by side with production data, an in-house effort is realistic. If the same people run live operations, the rebuild tends to stall, and an outside partner can carry the work under a written scope.
What access and inputs does an export and rebuild need from us?
The work needs a few concrete inputs before it starts. Someone with access to the Make organization must export the blueprints, because the export only covers scenarios the signed-in user can open. The team should also provide a list of every app used in each scenario, the owner of each account, and a way to obtain or reissue the credentials for those apps. A test environment matters most. Rebuilt scenarios should run against sandbox accounts or copies of real data, not live customer systems, until outputs are compared. Collect these items in a written inventory: scenario name, trigger type, apps, owner, schedule and data sensitivity. That inventory drives both the internal plan and any quote.
How long does it take to confirm a rebuilt scenario works?
The confirmation time depends on how the scenario behaves, not on the export. Make does not publish a duration for this step, so the reader should measure it against their own environment. A simple scenario that reads one app and writes to another can be checked with a few test runs. A scenario that runs on a schedule, branches on conditions, or writes to finance, HR or patient systems needs side-by-side runs over several cycles, plus review by the business owner. Ask any implementation partner to state the test plan, the exit criteria and the number of parallel runs in writing, and make acceptance depend on those criteria rather than on a date.
What does the 2 MB blueprint limit mean for large scenarios?
Make cannot save an imported blueprint larger than 2 MB. Most scenarios fall well under that size, but large scenarios with many modules, long mapping expressions, embedded code or extensive error handling can approach it. The practical response is to check file sizes before import, split very large scenarios into smaller linked flows where the logic allows, and keep a record of the original JSON in your own storage. The limit also matters for planning: a blueprint that cannot be imported into Make is not a backup of the working scenario in every case, so the team should keep the scenario documentation and the inventory alongside the file.
Does an exported blueprint include our passwords and API keys?
No, connections are not included in a blueprint, and Make states that they must be recreated after import. The blueprint keeps modules, module settings and mapped values, so a reviewer should still scan the JSON for hard-coded tokens, internal hostnames and personal data before the file leaves Make. Store exported files in a restricted location, log who handled them, and delete copies once the rebuild is verified. Treat the credentials for each app as a separate handover, issued by the account owner for each system and recorded in the target platform's secrets store.
When is outside help worth scoping as a fixed-scope engagement?
Outside help makes sense when the rebuild is larger than the team can test alongside daily operations, or when the scenarios touch regulated data. DeployOpen plans, implements, integrates and documents self-hosted open-source platforms inside the client's own infrastructure, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. A typical scope covers the scenario inventory, the target platform setup, the rebuild of agreed scenarios, the connection handover, test evidence and documentation. DeployOpen does not publish a price list, so the quote follows from that written scope. Ask any provider to split one-time work from recurring support and to confirm what the handover includes.
How to verify an export before you rely on it
Treat a blueprint export as a claim that needs testing, not as a finished backup. The first check is a comparison between the exported file and the live scenario: count the modules, then compare the module settings and mapped values for each one against what the Make editor shows. A blueprint holds the scenario's modules, module settings and mapped values, so a missing module or a changed mapping is the most likely defect. Record the scenario's name, module count and last edit date next to each file so the comparison can be repeated later. Each exported file is named after its scenario, for example name.blueprint.json, so confirm that every scenario you need has its own file and that none were overwritten during a bulk export.
Next, confirm that each file opens as valid JSON and imports cleanly into a test environment. Remember that Make refuses to save imported blueprints larger than 2 MB, so a file that exports successfully may still fail on import. Check the file size before you start, and treat any failure as a finding to record, not a reason to retry silently. Then run one scenario end to end. Because connections are not included in a blueprint and must be created again after import, this test must use freshly created connections under accounts the team controls. Compare the output of the rebuilt run with the output of the live scenario for the same input, field by field. Expect differences in credentials and connection identifiers, and document them rather than treating them as export defects.
Finally, keep a signed record of what was exported, when, by whom and from which account, with the file checksums and the results of the checks above. Sign it with the team's standard method, whether that is a named approver in a change record or a digital signature from your document system. Store the record outside the automation platform so it survives a platform change. Run the checks yourself or through your own engineers, not only through the vendor or the implementer who produced the export, because the team that owns the data is the one accountable for it. Ask your implementation partner to document the checks in their deliverables, and confirm how long you need to retain the records under your own policies.
How DeployOpen scopes and delivers a Make data exit
DeployOpen approaches a Make data exit as a fixed-scope engagement inside your own infrastructure. We inventory the scenarios, export each blueprint, and rebuild the flows on self-hosted platforms in your network, with the connection and credential work tracked as its own deliverable.
How we scope
- Inventory every Make scenario, its triggers, modules and schedule, and which ones your business depends on
- Record the connections and accounts each scenario uses, since blueprints do not carry them
- Agree the target platform, hosting location and the written deliverables before any work starts
How we build
- Export each scenario as a blueprint .json file and check it against the 2 MB import limit before rebuilding
- Rebuild scenarios on the agreed self-hosted platform and recreate every connection with owner-approved accounts
- Test each rebuilt flow against the original Make run history with sample inputs and recorded outputs
How we hand over
- Deliver a document per scenario covering its logic, connections, owners and known differences from Make
- Provide a list of credentials to rotate and the people who must re-authorize each connection
- Keep blueprint exports and test records in your own storage as evidence of what was moved and when
How we support
- Run the fixed-scope handover, then confirm with your team that each scenario runs as documented
- Offer ongoing support, upgrades and continuous testing of rebuilt flows as a retainer
- Agree in writing who owns the platform, backups and the operational runbook after handover
