How to export Tray.ai projects as JSON before the contract ends
A renewal, a pricing change or a data residency requirement is forcing a move away from Tray.ai, and the first question is what can leave the platform. Tray.ai projects can be exported as JSON, and that file describes the workflow logic: the steps, their order and the settings configured inside each project. It does not carry the data processed by those workflows, the authentication secrets stored for connected applications, or the access control around users, roles and environments. Exact export options, file formats, size limits and whether every project and version is covered are not confirmed here, so check Tray.ai's current documentation or ask your account team in writing before you rely on any export.
Use each exported file as an inventory and a rebuild plan. For every project, note the triggers, the connectors, the data mappings and any callable workflows it depends on, because a rebuild must reproduce each of them. Expect credentials to be missing. In comparable tools such as Make, the exported blueprint keeps modules and mapped values but leaves connections to be recreated after import, and you should confirm with Tray.ai how its connections, on-prem agent dependencies and user permissions are handled. Record those answers, since they set the rebuild effort, and keep a separate list of stored secrets that must be rotated so none of them carries over by accident.
DeployOpen helps teams turn that inventory into a plan: grouping projects by business owner and dependency, choosing a target such as self-hosted n8n or Windmill inside your own infrastructure, and cutting over one project at a time. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and a quote follows from that written scope. Before the notice period begins, ask Tray.ai for the export format, its limits, how workflow history is retained and the date by which exports must be complete, then write those answers into your migration plan.
What Tray.ai's JSON project export includes and its limits
This table shows which parts of a Tray.ai project are likely to appear in a JSON export and which parts you must record separately. Tray.ai has no researched export limits, so every limit in the right-hand column is an item to confirm with Tray.ai before your contract ends. Treat the export as a structural inventory and rebuild plan, not as a complete backup.
| Data type | Export method | Format | Limits to confirm |
|---|---|---|---|
| Project and workflow definitions | JSON export of each project from the Tray.ai interface or as Tray.ai directs | JSON | Whether all workflows in a project export in one file or one file per workflow |
| Step configuration and field mapping | Included in the workflow JSON as the step settings and data mappings | JSON | Whether expressions, custom code and variables are exported in full or in part |
| Triggers and schedules | Included in the workflow definition, schedule and webhook settings may need separate checks | JSON | Whether webhook URLs, polling intervals and schedules transfer or must be recreated |
| Reusable and callable workflows | Exported with their parent project only if they belong to the same project | JSON | How cross-project callable workflows are referenced and whether they export with their callers |
| Connector and authentication references | Connector names and auth slot names appear, but credentials are not part of the project file | JSON references only | Whether any token, key or password value is included, and the exact list of connections to recreate |
| Stored data and workflow run history | Not part of the project definition; retrieve through logs or Tray.ai's own reporting if needed | Not applicable in project export | Retention period for run logs and whether any export tool covers them |
| Access control and environment settings | Project sharing, roles and environment configuration sit outside the project file | Not applicable in project export | Which users, roles and environment variables you must document by hand |
| Version history and change logs | Not part of the standard project file, so record your own versions before export | Not applicable in project export | Whether Tray.ai keeps earlier versions available and for how long |
What the JSON export leaves behind and how to capture it
A Tray.ai project export gives you the workflow logic, but not the operational state around it. Each card below names one thing the file leaves behind, with a workaround to capture it before the contract ends. Treat the export as the rebuild plan and these checks as the inventory around it.
Stored data and run history
The JSON file describes how a workflow is built, not what it has processed. Run history, logs, cached lookup data and any values saved in project storage stay in Tray.ai. Before the contract ends, record the retention period your plan provides, then export the run records you need for audit or dispute purposes. Ask Tray.ai in writing how long run logs remain available after termination. Keep a copy of any reference tables the workflows depend on, because they will not come back with the project.
Connection credentials and secrets
Connections do not travel with the project. Each Tray.ai authentication, API key, OAuth grant and stored password must be re-created in the target tool, and the export gives you no values to reuse. Build a secrets register that lists each connector, the owning system, the account used, and the scope granted. Store the actual values in your own vault, not in a spreadsheet. Make's documented blueprint export follows the same pattern, so expect this gap in most iPaaS tools.
Access control and user roles
Project sharing, folder permissions, and who may edit, run or publish a project are administrative settings that sit outside the workflow file. Ask a Tray.ai administrator to export a role matrix that lists each user or group, the projects they can reach, and their permission level. Use that matrix to define groups and approval rules in the new platform before anyone is given access. Check whether single sign-on mappings are part of the handover, since these must be rebuilt in your identity provider.
On-prem agent setup and network rules
If a project calls internal systems through a Tray.ai on-prem agent, the agent, its host and the firewall rules that allow it to reach those systems are not in the export. Document each agent, the host it runs on, and every internal endpoint its workflows call, including ports and protocols. This list tells you which systems the new runtime must reach from inside your network. Confirm with your network team which outbound rules can be reused and which need a new request.
Environment, schedule and trigger settings
Environment variables, scheduled run times, webhook URLs and trigger state are configured in the platform rather than inside the workflow definition. A rebuilt workflow may run with the wrong schedule or accept webhooks at new addresses, which can break upstream senders. Record every trigger, its schedule, its endpoint and which environment it belongs to. Plan the cutover so that each trigger is switched off in Tray.ai and enabled in the new platform in the same change window, and confirm that upstream systems point to the new endpoints.
How to read the exported files as a rebuild plan
Treat each exported JSON file as a specification draft, not as an import package. Each project file lists its workflows, steps, field mappings and dependencies between steps, and those elements become the inventory you rebuild from. Start by listing every workflow and noting which steps call other workflows, because callable workflows often hold logic that several projects share. Map each Tray.ai step to the equivalent action in your target tool, and flag any step with no clear equivalent so it is decided on paper before anyone builds it. Because the export carries no stored data, no access control and no authentication secrets, every step that needs a credential must be listed as a dependency to resolve during the rebuild.
Annotate each file before any build starts. For every workflow, record the owner, the business purpose, the upstream systems that trigger it, the downstream systems it writes to, and the connection each step requires, along with the account that holds it. Add the schedule or trigger type and the expected volume, which you will need to size the target environment. Store these notes next to the JSON in version control or your document system so they travel with the file. A reviewer should be able to read one annotated file and understand what the workflow does and who depends on it without opening Tray.ai. Confirm the owner and the purpose with the business team, since the exported logic alone does not explain why a workflow exists.
The target tool determines how you read the file. n8n models work as a canvas of nodes connected in a sequence of executions, while Windmill models logic as scripts, flows and apps that can be written in code and versioned. The same Tray.ai project may become several n8n workflows or one Windmill flow with scripted steps, depending on how the logic branches and how much custom code it needs. Decide the target for each workflow group before rebuilding, and record that decision in the annotations. Plan to test each rebuilt workflow against sample inputs and compare its outputs with the production results from Tray.ai before you cut over. Confirm with each vendor how its current release handles the constructs your projects use, such as loops, error handling and sub-workflows.
How to export each project and workflow in sequence
This sequence produces a complete, verified set of Tray.ai project JSON files, a separate record of connections and secrets, and an inventory you can check against the live tenant before the contract ends. Work through the steps in order, because later checks depend on the freeze and the inventory taken at the start.
Freeze change requests on Tray.ai projects
Ask the platform owner to announce a change freeze on every project in scope, so no workflow is edited while you export. Name one person who approves any exception and records it. Your check is a written freeze notice with a start point, plus a note of any project that is still being changed. Confirm how your Tray.ai tenant lets administrators restrict edits, since the controls and roles are described in the current product documentation.
List every project and workflow owner
Build an inventory of every project, workflow and callable workflow in the tenant, with the owner, the environment it runs in and whether it is scheduled, triggered by a webhook or started by another workflow. Ask each owner to confirm they will support the export and the later rebuild. The output is a spreadsheet with one row per workflow and a named owner for each row. Confirm where Tray.ai shows owners and environments, because menu locations change between releases.
Export each project and workflow as JSON
Export each project and workflow from Tray.ai as a JSON file, using the export option in the current product documentation or project menu. Name each file with the project, workflow and export date, and record the tenant and environment it came from. Keep a log that lists every file produced and any export that failed. Confirm the export scope before you start: the JSON captures the workflow definition, and you should verify what it leaves out, including stored data, access control settings and authentication secrets.
Store the files in a versioned repository
Commit the exported files to a Git repository with history turned on, and restrict read and write access to the migration team. Store the repository on infrastructure you control, so the files do not depend on the vendor remaining available. Tag the first commit with the freeze date. The check is that each file has a commit, a hash and a named author, and that only the migration team group can read the repository.
Record connections and secrets separately
Build a separate register of every connection, account, API key, OAuth client, certificate and webhook secret that the workflows use. Record which system each one authenticates to and who owns the credential. Keep this register out of the workflow repository and store secret values only in a secrets manager that the migration team controls. The output is a connection register that the rebuild will use to recreate each authentication in the new platform. Confirm with Tray.ai whether any secret values can be exported at all, since the export may contain only references.
Verify counts against the Tray.ai inventory
Compare the number of projects, workflows and steps in each exported file with the inventory from the second step. Each project and workflow should appear once in the files, and each step count should match what you see in the live workflow editor. Investigate any gap before you continue, including workflows that were added during the freeze or that call other workflows. The output is a signed-off reconciliation sheet that the migration lead reviews.
Check each file for mappings and error handling
Open the live workflow next to its exported file and confirm that triggers, actions, field mappings, conditional branches, loops and error handling match. Note any step that depends on a connection, a stored value or a lookup that the file does not contain, and add it to the rebuild list. Mark each workflow as verified, partially verified or blocked, with the reviewer's name and date. This check shows which files can serve as a rebuild plan and which need manual documentation.
Confirm each backup copy opens
Restore a copy of the repository to a clean machine or test environment and open each JSON file with a standard JSON parser and a text editor. Confirm that every file parses without errors and that the restored repository matches the commit hashes in your log. Keep a dated record of this test. The output is proof that the archive is readable without access to the Tray.ai tenant, which matters once the contract and login access end.
Which platform to rebuild in once the files are exported
n8n is a fair-code visual workflow platform that fits department-wide automation built from connectors, with custom JavaScript or Python where a node is not enough. Its main codebase is under the Sustainable Use License, which allows use and modification for your own internal business purposes or for non-commercial or personal use. That covers running it inside your company, but it does not cover offering n8n as a hosted service to others.
- Internal use limits: Confirm with counsel that your planned use, including any work for subsidiaries, partners or customers, falls within the internal business purpose allowance in the license.
- Enterprise files: Files with
.eein their name or directory are not covered by the Sustainable Use License and need a valid n8n Enterprise License, so review any code you add or modify before deployment. - Community edition: Without a license key, n8n runs as the free Community edition. Business and Enterprise editions are enabled by adding a license key, and SSO and LDAP are listed only for those editions.
- Queue mode: Main, worker and webhook processes must share the main instance's encryption key so workers can read stored credentials, so plan secret distribution before scaling out.
- Hosting: Documented installs include Docker Compose and major cloud providers, which suits teams that run the platform in their own cloud account.
Match n8n to exports dominated by app-to-app flows and scheduled jobs. Check the license terms and edition features against your plan before committing.
Windmill is a script-first platform that suits engineering-led teams whose exported workflows contain custom logic, data transformations or internal tooling. Its scripts can be written in Python, TypeScript, Go, Bash, SQL, GraphQL, PowerShell, Rust and more, and they can be composed into flows or low-code apps. The licensing depends on how you obtain the software.
- Source builds: Source code compiled without the enterprise feature flag is under AGPLv3 and Apache-2.0, so review the obligations of AGPLv3 before you modify and offer it over a network.
- Community Edition images: Prebuilt images include proprietary code that is free for internal use, while managed services or reselling require a commercial license. Confirm which build your team will run.
- Self-hosting: The repository documents Docker Compose and Kubernetes Helm charts, with support for external PostgreSQL databases such as AWS RDS, GCP Cloud SQL and Azure.
- Enterprise features: SAML and SCIM, audit logs, external secret backends and full Git sync are listed on the pricing page for the Enterprise Edition, so check them against your audit requirements.
- Sizing: The README gives a rule of thumb of one worker per vCPU with 1 to 2 GB of RAM, which is a starting point to validate in your own load tests.
Match Windmill to exports where the logic lives in code, scheduled jobs or internal APIs. Confirm the build, edition and features you need before you plan the rebuild.
The right platform depends on the mix of workflow types in your export rather than on a general preference. Sort each exported project into groups before you choose, because a platform that suits connector-driven flows may be a poor fit for code-heavy jobs, and the reverse is also true. A mixed estate may justify running both platforms, each with a clear owner.
- Connector-led flows: Trigger-and-action flows between SaaS apps map most directly to n8n's visual canvas and node library.
- Code-heavy jobs: Scripts that transform data, call internal services or run on a schedule map more directly to Windmill's script model.
- Callable sub-workflows: Tray.ai projects that call other projects need a plan for how the same reuse will work in the target platform.
- Operator roles: Decide who builds, who reviews and who runs the platform, since Windmill's script focus suits developers while n8n's canvas suits a wider group.
- Edition needs: Compare the features your controls depend on, such as SSO, audit logs and secret backends, against the editions listed for each platform.
Before you decide, confirm the license terms, edition features and hosting model with each vendor in writing.
Questions buyers ask before exporting Tray.ai projects
Is the Tray.ai JSON export enough to move without a consultant?
The JSON export is a useful starting inventory, but it is rarely enough on its own to rebuild workflows. The file describes the structure of each project, its steps and their configuration, but it does not carry the stored data, the access control model, or the authentication secrets behind each connection. Your team will need to recreate those connections and verify every step against live systems. Teams with a small number of simple projects and a capable engineer often do this in-house. Teams with many projects, custom connectors or on-prem dependencies usually want outside help for the rebuild plan. Confirm the exact export contents for your plan with Tray.ai before you rely on the file.
What makes the export effort grow or shrink?
Effort rises with the number of projects and workflows, the number of custom connectors, the count of credentials that must be re-entered, reliance on the on-prem agent, and how much error handling each workflow contains. Each of these adds steps that the JSON file cannot complete for you. A single project with three standard connectors is a very different job from fifty projects that call shared sub-workflows and read from an internal database through the agent. Before you start, count projects, list connectors by type, and record which systems each project touches. That list is what turns a vague estimate into a scoped plan.
How long does the export and rebuild work take?
The duration depends mostly on the quality of your inventory. A complete list of projects, owners, connectors, credentials and downstream systems lets the rebuild be sequenced and estimated with some confidence. Without it, time is lost discovering dependencies after cutover has begun. No duration is stated in the source material for this migration, so ask for a timeline based on your own inventory rather than relying on a general figure. A quote should show how the timeline changes if the inventory is incomplete or if projects share sub-workflows.
What must our team supply before the migration starts?
Three groups of people are needed. Project owners must confirm what each workflow does and which business rules it enforces. System administrators must grant access to the target systems, the on-prem agent's network and any test environments. Secret holders, usually the people who own the service accounts and API keys, must be available to re-issue credentials, because the export does not provide them. Name these people per project during the inventory. Missing secret holders are one of the most common causes of delay, so confirm their availability before you commit to a schedule.
Can we export and rebuild the projects in-house?
Yes, many teams do, provided they have engineers who can read the JSON structure, a test environment for the target platform, and time to validate each workflow against real data. In-house work is most practical for a limited number of projects with standard connectors. It becomes harder when projects depend on on-prem connections, custom code or error handling that the team did not write. If you choose a fixed-scope engagement with DeployOpen, the scope, deliverables and timeline are agreed in writing before work starts, and a quote follows from that scope. DeployOpen does not publish a price list.
Which license terms should we check before choosing n8n or Windmill?
Check the license of the exact edition and files you plan to run, not only the project name. n8n's main codebase is under the Sustainable Use License, which permits use for your own internal business purposes or for non-commercial or personal use, while files with .ee in their name require a valid n8n Enterprise License, according to the n8n LICENSE file. n8n's pricing page lists a free self-hosted Community edition, a Business plan at 667 euros per month billed annually that is currently self-hosted only, and Enterprise at custom pricing. For Windmill, the Windmill pricing page lists a free self-hosted Community Edition limited to 3 workspaces, 50 users and 4 groups as of October 2026. Confirm which edition fits your user count, identity needs and whether you intend any commercial reselling.
Does the export keep our access control and secrets safe during the move?
The export does not carry authentication secrets, so no credential material should be expected in the files. Treat the JSON as sensitive anyway, because it reveals system names, endpoints, field mappings and business logic. Store exports in a restricted location, limit who can open them, and remove copies once the rebuild is verified. When you recreate connections on the target platform, use a secrets store your security team approves and record who holds each credential. Ask your security team to review the access model of the new platform before cutover, because role assignments do not transfer through the export.
What to plan before the Tray.ai renewal or termination date
A Tray.ai export only helps if the contract gives you enough time to use it. The cards below cover the contract dates, export window, data terms, staffing, parallel running and license checks that should be settled before access ends. Confirm every term with Tray.ai and your own legal team, because notice periods and fees are set in your agreement, not in this guide.
Notice periods and renewal dates
Find the notice period, auto-renewal clause and the exact date your current term ends. Check whether notice must be given in writing, to a named contact, and by what date. Record these dates in your migration plan so the export work is scheduled backward from the last day you can still act. Ask Tray.ai to confirm them in writing, and have your legal team review any clause that extends the term automatically.
Export window before access ends
Ask how long read access to projects, logs and project files remains after the subscription ends, and whether that access covers exports. Confirm whether an export can still be taken after notice is given and whether support can help if an export fails. Plan the export in a single pass per project so you are not depending on the last days of access.
Data retention and deletion terms
Request written terms covering how long Tray.ai keeps workflow data, execution records and logs after termination, and how deletion is confirmed. Ask which data is returned, which is deleted and whether backups are purged on a stated schedule. Your data processing terms and records of processing should match these answers before you move any customer data into a new platform.
Owners and staff time
Name one owner for the contract dates, one for the export inventory and one engineer per workflow group who can rebuild it. Each owner needs enough time before the deadline to review exported JSON, document dependencies and sign off on the cutover. Ask Tray.ai and your integration partner to confirm the effort in writing rather than assuming a fixed timeline.
Parallel running of old and new workflows
Keep Tray.ai running until each rebuilt workflow has matched it on real inputs, including error paths and scheduled runs. Run both versions side by side for a defined period and compare outputs, then switch triggers project by project. Stop the old trigger before the new one starts so records are not processed twice, and keep the Tray.ai project in place as a fallback until the cutover is accepted.
Target platform license checks
Before choosing n8n or Windmill, confirm that your intended use fits the license. n8n's Sustainable Use License covers internal business use, but files with .ee in their name need an n8n Enterprise License. Windmill's Community Edition prebuilt images include proprietary code that is free for internal use, while managed services or resale need a commercial license. Have your legal team check these terms against your deployment model.
How DeployOpen scopes, delivers and supports a Tray.ai export and migration
DeployOpen treats the Tray.ai export as the first step of a fixed-scope engagement, not a file dump. We agree in writing which projects, connections and access rules are in scope, then rebuild and document them in your own infrastructure so the exported files become a working plan.
How we scope
- Inventory every Tray.ai project, workflow and on-prem agent dependency before any export starts
- Record which connections, credentials and access rules the JSON export leaves behind and who recreates them
- Agree in writing the deliverables, timelines and acceptance criteria for the export and rebuild
How we build
- Export each project and workflow as JSON and map its triggers, steps and connectors to the target platform
- Rebuild workflows in your chosen self-hosted platform, recreating authentications with your own secret handling
- Test each rebuilt workflow against the original behavior and record the differences for your sign-off
How we hand over
- Deliver a written migration record listing each project, its status, owner and open dependencies
- Document how each rebuilt workflow runs, is versioned, and how credentials are stored and rotated
- Walk your team through the cutover plan so each project moves in a controlled order
How we support
- Offer ongoing support, upgrades and continuous testing for the rebuilt workflows as a retainer
- Keep the platform hardened and backed up under the same written scope after handover
- Confirm with your team which support terms and response expectations apply before work begins
