Migrate from Tray.ai to n8n

Who moves off Tray.ai to n8n, and how much work it really is

The migration from Tray.ai to n8n is a project-by-project rebuild run in parallel with the existing platform, not a file import. Each Tray.ai project has to be recreated as an n8n workflow, tested against the same inputs and outputs, and switched over only when its owner signs off. Teams usually start this work when a renewal or quote change forces a decision, when data residency rules rule out the current hosting region, or when the on-prem agent is one they want to retire. Plan the timeline around those triggers, and avoid promising a single cutover date for the whole estate. The work is usually shared across three groups. The platform or integration team rebuilds workflows, re-creates authentications and runs the n8n instance. Security and compliance reviewers check where credentials are stored, who can edit workflows, and how the self-hosted environment is hardened and logged. Business owners of each workflow confirm that the rebuilt version does what the old one did, including edge cases that exist only in practice. Effort and risk depend mostly on how many projects exist, how many depend on callable workflows and how many rely on the on-prem agent. Projects that call other projects or reach internal systems deserve the most review time. Confirm Tray.ai's export scope directly with Tray.ai before you plan, because the exact contents of a project export, including whether credentials and stored data are included, must come from the vendor and not from assumption. On the n8n side, check licensing before you commit. The n8n main codebase is under the Sustainable Use License, which allows use for your own internal business purposes or for non-commercial or personal use. Confirm that your intended use fits those terms, particularly if you plan to offer workflows to customers or other organizations. Any file with .ee in its name requires a valid n8n Enterprise License. Ask counsel or your licensing lead to review the proposed deployment model and record the decision before the first workflow is rebuilt.

Which Tray.ai capabilities map to n8n cleanly, which need rework and where the gaps are

This table maps each Tray.ai capability to its closest n8n equivalent and marks the migration effort as clean, needs rework or gap. Read the notes alongside the confirm column, because several n8n features are gated to Business or Enterprise editions and Tray.ai details should be checked against your own contract and tenant.

Capability	n8n equivalent	Migration note	Confirm with
Visual workflow builder	Visual canvas with custom JavaScript or Python code steps	Needs rework: flows are rebuilt by hand, and logic written in Tray.ai expressions must be rewritten	Tray.ai export files and n8n editor walkthrough
Connectors	More than 1,500 integrations advertised by n8n, with HTTP request nodes for anything missing	Needs rework: each connection is recreated and every Tray.ai connector needs a matching n8n node or an HTTP call	Tray.ai connector list and n8n node catalog for each app
Triggers and webhooks	Webhook and app trigger nodes, with webhook processing in queue mode	Clean for standard webhooks: URLs change, so upstream senders must be repointed	Tray.ai trigger settings and n8n webhook documentation
Scheduled runs	Schedule trigger node	Clean: cron-style schedules are recreated, with time zones checked on the new host	Tray.ai schedule settings and server time zone
Reusable or callable workflows	Sub-workflows called from other workflows	Needs rework: Tray.ai callable workflow signatures must be mapped to n8n inputs and outputs	Tray.ai callable workflow definitions
Authentication and credentials	Encrypted credential store in the n8n database	Gap for migration: Tray.ai secrets do not transfer, so every credential is re-entered; in queue mode the encryption key must be shared with workers	Tray.ai export scope and each app owner
On-prem reach to internal systems	Self-hosted n8n inside your network reaches internal databases, file shares and SOAP services directly	Needs rework: agent-based connections are replaced by network-local routing and firewall rules	Your network team and Tray.ai on-prem agent documentation
Environments and version control	Git-based environments on Business and Enterprise plans	Gap on Community edition: without a licensed plan, promotion between environments is manual	n8n pricing page and your edition choice
SSO and access control	SAML single sign-on and LDAP on Business and Enterprise plans	Gap on Community edition: SSO and LDAP are not included, so access is managed locally	n8n SAML documentation and identity provider setup
Logging and audit	Log streaming on Business and Enterprise plans, plus execution history	Gap on Community edition: log streaming is gated, so plan an export or SIEM feed	Tray.ai audit log scope and your SIEM team
High availability	Queue mode with workers on Redis and PostgreSQL; multi-main setup on Enterprise self-hosted only	Gap for multi-main: confirm whether single-main queue mode meets your availability target	n8n queue mode documentation and n8n sales

What data, credentials and integrations have to be rebuilt by hand

A Tray.ai project export gives you the workflow logic to rebuild, but not everything the workflows depend on. The cards below list what has to be recreated in n8n by hand, who must approve each piece, and what to confirm before you retire a Tray.ai project.

Use the export as the rebuild inventory

Export each Tray.ai project as JSON and use the files as the starting list of workflows, triggers, steps and callable components. Confirm with Tray.ai exactly what the export contains in your plan and version, because the export format is the vendor's to define. Anything it leaves out, including stored data, access control and authentication secrets, goes onto a separate manual list. The project owner signs off that the inventory matches what runs in production.

Recreate credentials and OAuth connections

Tray.ai authentications do not move into n8n as usable secrets, so each connection must be created again in n8n with the account it should use. Record which service account or user owned each connection, then have that owner or the system owner approve the new credential before any workflow is enabled. OAuth connections need fresh consent in the new instance. Check scopes against what each workflow really needs, not what the old connection granted.

Rebuild callable workflows as sub-workflows

Tray.ai callable workflows that other projects invoke need an n8n equivalent, usually a separate workflow that other workflows call with an Execute Workflow step. Map every caller to the new workflow and test inputs and outputs, since field names and data shapes often change during rebuild. Confirm the calling relationships from the exports rather than from memory. The integration owner signs off each callable interface before the callers are switched over.

Move data stores and lookup tables

Lookup tables and stored values held in Tray.ai do not come with the project export, so they must be extracted and loaded into a database you control, such as PostgreSQL. Decide which tables are reference data and which hold personal or regulated records, and set access for each. Workflows should read from the new database only after row counts and sample values match the source. The data owner approves the migration and the retention rules for the copied data.

Replace on-prem agent connections

Tray.ai reaches internal systems through an on-prem agent, which must be mapped to a direct connection from an n8n instance placed inside the same network. List every internal database, file share and SOAP service that the agent serves today, then confirm that the n8n host can reach each one under your firewall rules. The network security team approves each new path, and the owners of those internal systems approve the service account used.

Plan n8n encryption key management

n8n encrypts stored credentials with an encryption key, and in queue mode every worker and webhook processor must receive that same key to read the credentials. Decide where the key is generated, stored and backed up, and who can read it. Losing the key makes stored credentials unusable, so test restoration before cutover. The security lead approves the key storage method and the custodians who hold recovery copies.

How to turn the Tray.ai export into a rebuild plan

Build nothing until the inventory exists. Export each Tray.ai project and workflow, then record for every one its trigger, its owner, the systems and credentials it touches, how often it runs, and its failure history over the period you can still see. Rank the list by business impact, such as payments, customer messages or regulatory reporting, and separately by how much the export leaves out. Tray.ai's project files are a starting point, not a full picture: stored data, access control settings and authentication secrets are generally not part of a plain project file, so each gap must be filled from a source you control, such as the connected system's own records or the people who own the workflow. Confirm with Tray.ai, in writing, exactly what the export contains and what it omits before the contract end date is set, because that answer determines how much manual work the inventory will need.

Use the inventory to sort every project into one of three groups. Rebuild as-is applies to stable, high-impact projects whose logic is clear and documented. Simplify applies where the project carries steps added over years for edge cases nobody still needs, and n8n's per-execution model rewards fewer, clearer steps. Retire applies where the project has no recent runs, no named owner or a business process that has ended. Shared sub-workflows, the callable workflows that several projects invoke, deserve special handling: rebuild each one once as a single n8n sub-workflow that other workflows call, then point the dependent projects at it. Rebuilding the same logic in five places multiplies testing and credential work, and it is the most common way a migration ends up with five slightly different versions of one process.

Take the export before anyone's access is reduced. Licence renewals, offboarding of the engineers who built the projects and the removal of admin roles can all cut off the ability to export, and Tray.ai's export options should be confirmed with your account team while the account is fully active. Keep the exported files, the inventory and the decision for each project in version control so the rebuild has an auditable record. Plan for the points the export will not carry across cleanly, starting with every credential, which must be re-created in n8n and tested before a cut-over, and with any project that reaches an internal system through the Tray.ai on-prem agent, which needs a network path from the n8n runtime instead.

The migration sequence from inventory to decommissioning Tray.ai

The sequence moves Tray.ai projects to a self-hosted n8n instance one project at a time, with a sign-off at each stage so that no Tray.ai project is switched off before its n8n replacement has been checked. Each step produces a record the owning team and security reviewers can approve.

Inventory every Tray.ai project and its dependencies
Export each project from Tray.ai as JSON and build a register that lists the owner, the trigger type, the connected systems, the credentials each project uses, and any callable workflows or on-prem agent connections it depends on. Export files do not carry authentication secrets or stored data, so record those separately from the exports. Rank the projects by business criticality and risk, with the lowest-risk candidates first. The output is a ranked inventory that the business owners and the security team sign off on before any build work starts.
Build the self-hosted n8n platform
Deploy n8n inside your own cloud account or data center using the Docker Compose or cloud provider install described in n8n's hosting documentation. Choose the edition before you build: the Community edition runs without a license key, while Business and Enterprise editions require a license key. If you need SSO through SAML, confirm it is included in the chosen plan and configure it with your identity provider. Set up backups for the database and the encryption key, and confirm that the instance can reach the internal systems listed in the inventory. The output is a documented platform build, with the edition, hosting model, access controls and backup approach signed off by the platform and security owners.
Rebuild and test one low-risk pilot project
Select the lowest-risk project from the ranked inventory and rebuild it in n8n against test systems rather than production. Recreate each authentication in n8n's credential store, because exported files do not carry secrets. Run the pilot with the same sample inputs used in Tray.ai and compare outputs, field mappings, error handling and run counts. Record every difference and decide whether it is an accepted change or a defect to fix. The output is a comparison report for the pilot that the project owner and the security reviewer approve before the team moves on.
Run in parallel and cut over project by project
For each project in ranked order, run the Tray.ai version and the n8n version side by side and compare their results against the checks agreed for that project. Once the checks pass, turn the n8n version live for that project only and keep the Tray.ai version available to switch back to. Switch off the Tray.ai version only after the owner confirms the n8n version is stable. Where a Tray.ai project relied on an on-prem agent connection, confirm that the n8n instance reaches the same system directly from inside the network. The output is a cutover record for each project that names the checks, the approver and the date the Tray.ai version was switched off.
Decommission Tray.ai and retain the evidence
After every project has cut over, revoke the credentials, API keys and on-prem agent registrations that were used only by Tray.ai, and remove any service accounts that existed only for the migration. Confirm with Tray.ai and your own records how project data, logs and exported files will be retained or deleted, and document the outcome. Keep the inventory, the pilot comparison, the cutover records, the credential revocation log and the data retention confirmation together in a location your auditors can access. Ask your compliance team which of these records they need to keep and for how long. The output is a closed decommissioning file that the CISO or compliance owner signs off on.

What drives migration cost and duration, and how to keep each one down

This table lists the factors that set the cost and length of a Tray.ai to n8n migration, why each one matters and how to contain it. Read the one-time rebuild, testing and cutover items separately from the recurring hosting, licence and operations items, since they are paid for in different ways.

Driver	Why it matters	How to contain it
Number of projects and their complexity	Each Tray.ai project is rebuilt as n8n workflows, and branching logic, error paths and data mapping drive most of the rebuild effort. This is a one-time cost.	Export every project to JSON first, score each one by steps and branches, and migrate the simplest projects first to build a repeatable pattern.
Distinct credentials and OAuth connections	Tray.ai's export does not carry authentication secrets, so every connection must be re-authorized in n8n. Many OAuth apps need re-consent, and this is a one-time cost that can stall cutover.	Build a credential inventory listing app, owner, account type and scopes. Create one n8n credential per app and reuse it across workflows.
On-prem connections to internal systems	Tray.ai reaches internal systems through an on-prem agent. A network-local n8n needs firewall rules, service accounts and network reviews for each internal target, which usually takes the longest.	List every internal endpoint with its protocol and owner before scoping. Run n8n inside the network so the agent connection is replaced rather than re-created.
Custom code and sub-workflow reuse	Callable workflows in Tray.ai must be mapped to n8n sub-workflows, and custom logic may need rewriting in JavaScript or Python. Shared components reduce rebuild work but raise test scope.	Identify shared callable workflows early and rebuild them once. Document any custom code and its inputs, outputs and dependencies.
Compliance evidence needs	Assessors may ask for change records, access reviews, test results and proof of who approved each cutover. Collecting this evidence adds effort to testing and handover.	Agree in writing which evidence is required, when it is captured and who keeps it. DeployOpen prepares evidence, but auditors and certification bodies issue any opinion.
Parallel run length	Running Tray.ai and n8n side by side doubles some costs for as long as both are live, and the period ends only when each project is confirmed. This is a recurring cost until the Tray.ai contract ends.	Set acceptance criteria per project, such as matching outputs over an agreed test window, so each project can be switched off on its own.
n8n edition choice	The Community edition is free to run. Business and Enterprise require a licence key. The pricing page lists Business at 667 euros per month billed annually and self-hosted only, and the Sustainable Use License limits use to internal business or non-commercial purposes. Confirm which features need a paid edition, such as SSO and LDAP, Git environments and log streaming, before choosing.	Map required features to editions before rebuilding. Ask the vendor to confirm current licensing terms for your use case and whether .ee files are in scope.
Hosting and database choices	Queue mode needs Redis and PostgreSQL, a shared encryption key across workers and webhook processors, and capacity planning for each component. These are recurring infrastructure costs.	Start with a single-instance Docker Compose install for pilot projects. Size queue mode only once execution volume is known, and record where the encryption key is stored.
Internal staff time to run n8n afterward	Someone must patch n8n, manage credentials, monitor executions and handle upgrades. This is a recurring cost that often costs more than the licence, and it stays after cutover.	Name an owner and a backup before cutover. Ask any retainer provider to define upgrade, monitoring and support tasks in writing.

What usually goes wrong in a Tray.ai to n8n move, and how to prevent it

Most failed Tray.ai to n8n moves do not fail on the workflow logic. They fail on credentials, network reach, licensing and edition choices that were never checked before cutover. The cards below cover the risks that tend to surface late, with a prevention step for each.

Credentials and OAuth grants lapse

Tray.ai exports carry workflow logic but not the authentication secrets behind each connection, so every OAuth app, API key and service account must be created again in n8n. Re-consenting under a personal user can break when that person leaves, and some grants have scopes narrower than the old workflow needed. Before cutover, inventory every connection by project, record the owning account and required scopes, and test each credential with a read-only call from the n8n instance. Assign a named service owner to every connection.

Silent changes in execution metering

n8n counts one execution as one run of a whole workflow, regardless of how many steps it contains. Tray.ai's task metering works differently, so a workflow that was budgeted by task count may behave differently in cost terms once moved. Error handling can also differ, so a step that retried or branched automatically in Tray.ai may simply fail or stop in n8n unless you build that behavior explicitly. Compare run volumes and error paths side by side for a week of traffic before retiring the original. Confirm how your own run volumes map to n8n executions.

On-prem connectivity never tested inside the network

A Tray.ai on-prem agent makes outbound connections from a host inside your network, so teams often assume an n8n instance placed in the same segment will reach the same systems. Firewall rules, DNS names, certificate chains and service accounts for internal databases frequently differ from what the agent used. Run a connectivity test from the actual n8n host to each internal endpoint, including failure cases such as expired certificates, before any workflow depends on it. Test from the n8n host, not from a workstation.

Mismatched encryption key in queue mode

In n8n queue mode, the main instance hands executions through Redis to worker and webhook processor nodes, which read and write workflow data in PostgreSQL. Those workers need the main instance's encryption key to decrypt stored credentials. A worker started with a different or regenerated key will fail on every credential-backed step, and the failure can look like an authentication problem rather than a configuration one. Store the key once in your secrets manager, inject it into every process at deployment, and verify a credential test on each worker. Never let a worker generate its own key.

Business features needed but not budgeted

Several controls teams expect on day one sit outside the Community edition. According to n8n's pricing page, SSO and LDAP, environments with Git, and log streaming are included only in the Business and Enterprise plans, and Enterprise adds dedicated support with an SLA. SAML single sign-on is documented for those same plans. If your identity or change-control policy requires these features, the edition decision is a budget and procurement item to settle before the pilot, not after. Map each policy requirement to an edition before choosing a plan.

Licensing scope mistakes

The Sustainable Use License covers use for your own internal business purposes and non-commercial or personal use. It does not cover offering n8n to customers as a managed service or reselling it. Separately, files with .ee in their name or directory are not covered by that license and require a valid n8n Enterprise License, so copying code from those paths into a Community deployment creates a compliance gap. Have counsel confirm that your planned use, including any internal platform team serving other business units or external partners, fits the license before you build. Check the scope of use against the license text, not the marketing page.

How the migration differs for small teams, large departments and regulated environments

A small team with a handful of projects and a single owner usually needs one n8n instance, a short inventory and a parallel run. The export is quick to review, so the main effort goes into rebuilding each workflow and proving it behaves the same way before the Tray.ai project is switched off. Whether the free Community edition is enough depends on which features the team needs, such as SSO or environments, and that should be confirmed against n8n's pricing page before installation.

One instance: Run a single n8n instance, typically with Docker Compose as documented in n8n's hosting guide, and keep the Tray.ai projects running until each replacement is verified.
Feature check first: Confirm which features the team depends on, such as SSO, environments or log streaming, because those are tied to the Business and Enterprise editions.
Re-create credentials by hand: Authentications do not carry over from the JSON export, so each connection is created again in n8n and tested with a live call.
Short parallel run: Run old and new workflows side by side for a defined period, comparing outputs for the same inputs before cutover.
Simple ownership: Record who owns the instance, who holds the encryption key and where backups are stored, since one person may hold all of these roles.

Before cutover, check that every trigger fires on the new instance and that no webhook URL still points at Tray.ai.

What buyers ask before moving from Tray.ai to n8n

What does a move from Tray.ai to n8n cost, and what drives it?

The cost is mostly labor, plus the n8n edition you choose. Self-hosted n8n Community edition has no license fee, according to n8n's pricing page, which lists it as free. Paid n8n editions are priced separately: the pricing page lists Business at 667 euros per month billed annually and self-hosted only, and Enterprise at custom pricing. The larger items are the people who inventory projects, rebuild workflows, recreate authentications and test cutovers, plus the infrastructure and staff time to run n8n afterward. Ask any implementation partner for a quote built from a written scope that lists the project count, connector count and credential count. The effort-drivers table on this page shows how those inputs change the total.

How long does a Tray.ai to n8n migration take?

The timeline depends on drivers, not a fixed number. The main ones are how many Tray.ai projects and callable workflows exist, how many distinct connectors and authentications they use, how many depend on the on-prem agent, and how much business logic relies on Tray.ai-specific behavior that needs redesign. Teams with a small number of projects and common SaaS connectors finish faster than teams with deep custom logic and many internal systems. Parallel cutover by project usually lengthens the calendar but reduces risk. Ask for a schedule tied to milestones in the written scope rather than a single end date.

Can our team migrate from Tray.ai to n8n without outside help?

A team with n8n experience can often handle a simple estate alone, meaning a small number of projects, mostly cloud connectors and few dependencies. The hard parts are the inventory and the credential work. Tray.ai's JSON export does not carry authentication secrets, so every connection must be recreated in n8n and approved by the system owner. Callable workflows, error handling and data mappings also need careful review. Teams without a clear inventory, or with on-prem agent dependencies, should plan for more time or bring in help. Confirm your capacity against the actual inventory before deciding.

What does our organization need to provide for the migration?

The migration needs named owners, approvals and access before engineers can work. Each Tray.ai project should have a business owner who confirms its purpose and cutover date. Security or application owners must approve recreating each credential in n8n, often with new service accounts and least-privilege scopes. You will also need test systems or sandbox accounts for each connected application, and a staging n8n instance. For on-prem systems, the n8n host must reach internal databases and services on the network, which usually requires firewall change requests. List these dependencies in the written scope so they are scheduled before rebuild work starts.

Does an outside partner help, and what should a written scope include?

An outside partner can plan, rebuild, test and document the migration, but it does not replace your owners or approvals. DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms in your own infrastructure, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts. Ask any partner for a written scope that includes the project inventory and its method, the number of workflows to rebuild and test, the credential recreation process and approvals, the cutover plan by project, rollback steps, backup and upgrade responsibilities, handover documentation, and the post-cutover support terms.

Can we use Tray.ai's export as the migration plan?

Use the export as a starting inventory, not as a complete migration file. A Tray.ai project export is JSON that describes the workflow structure, but it does not carry stored data, access control or authentication secrets, so credentials must be recreated in n8n. Confirm exactly what your Tray.ai export includes with Tray.ai before your contract ends, because access may stop at that point. Export every project and workflow while you still have access, store the files securely under your own retention rules, and record which callable workflows and on-prem connections each project depends on.

Does n8n's license allow our intended use?

n8n's main codebase is under the Sustainable Use License, which allows use for your own internal business purposes, along with non-commercial or personal use. Using n8n to automate your own company's workflows generally fits the internal business purpose, but offering n8n as a service to third parties does not. Files with .ee in their name or directory are not covered by that license and require a valid n8n Enterprise License, so check which features you plan to use. Confirm the boundary with n8n or your legal team against the LICENSE.md file before committing to a deployment model.

How DeployOpen scopes, runs and supports a Tray.ai to n8n migration

DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For a Tray.ai to n8n migration, we start from a written scope that covers your project inventory, the workflows to rebuild and the network path to each internal system.

How we scope

Inventory every Tray.ai project, workflow and callable workflow, with owners and business purpose recorded for each.
Confirm which connectors, on-prem agent connections and authentication methods each workflow depends on.
Agree in writing which projects move, which retire and the cutover order, before any build work starts.

How we build

Rebuild prioritized workflows in n8n inside your cloud account, data center or air-gapped network.
Recreate authentications as n8n credentials and set up network-local connections to internal systems without an agent.
Test each rebuilt workflow against the Tray.ai output it replaces, and record the results for review.

How we hand over

Document the n8n deployment, credential ownership, workflow naming and the runbook for each migrated project.
Confirm the license edition you run against the features your workflows and access controls require.
Cut over project by project, with a rollback step and a retirement record for each Tray.ai project.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover.
Plan n8n upgrades and backups with your team so workflows and encryption keys remain recoverable.
Ask for the support scope, response expectations and exit terms in the quote before engagement starts.