How to export your data from Workato

What you can export from Workato and what you cannot

If a renewal, a price change or an exit decision means you need your recipe inventory outside Workato, start with the recipe lifecycle management export. It builds a manifest that Workato turns into a zip of JSON files covering recipes, connections, custom connectors, lookup tables, recipe functions, environment properties and, optionally, tags. Those files describe what your automations do and what they depend on. They do not carry run history, live state or a running copy of the flows, so the package is a specification and inventory, not something you can switch on in another platform.

The manifest adds dependent assets from the selected folder and its subfolders automatically, which makes folder structure the first thing to check. Workato advises keeping shared connections in the Home folder so they can be exported from different source folders. Lookup tables deserve a separate check: Workato exports only the table headers by default, and rows are included only when Include data is selected for each table. Exporting every project in a workspace also requires the create projects privilege, so confirm that the account running the export holds it before you plan around a full export.

Treat the zip as the starting point for an inventory. Ask Workato's documentation and your own administrators what the export does not include for your edition and configuration, and record that gap explicitly. Connection credentials, secrets and operational data should be handled as separate work with your security team rather than assumed to be in the package. Then compare each exported recipe against what actually runs in production, because the JSON shows design, not the state of each run.

Which Workato assets the manifest package includes

This table lists each asset type a Workato manifest can carry, how it is pulled into the package, and the limit that affects completeness. Read the lookup table and privilege rows first, because those are the two places where an export looks finished but is missing data or fails for a user without rights. The package is a zip of JSON files, so it works as an inventory and specification, but it does not replace a backup of live table rows or connection credentials.

Asset type	How it is exported	Limit or condition
Recipes	Included from the selected folder and its subfolders as JSON	Dependent assets are added automatically
Connections	Included as JSON representations in the package	Keep shared connections in the Home folder so they export from any source folder
Custom connectors	Included as JSON representations in the package	Confirm the connector code and dependencies are present in the target workspace
Lookup tables	Table headers are exported by default	Rows are included only when Include data is selected for each table
Recipe functions	Included as JSON representations in the package	Confirm each function is referenced by an exported recipe
Environment properties	Included as JSON representations in the package	Values must be re-entered or mapped for each target environment
Tags (optional)	Added only when the tags option is selected	Not part of the package unless selected at export
Export all projects in a workspace	Single manifest covering every project	Requires the create projects privilege

What stays behind in Workato and how to capture it

The recipe lifecycle export gives you the definitions of your flows, but it does not give you everything an integration team relies on. The cards below cover what sits outside the documented package and how to capture it before a migration or exit. Confirm each boundary with Workato's documentation and your account team rather than assuming the package is complete.

Run history and execution records

A manifest describes how recipes are built, not what they did. Job history, success and failure counts, and the payloads of past runs are operational records that a package of recipe JSON does not carry. Before you retire a flow, decide how long you need these records for audits, incident reviews or reconciliation. Ask Workato what run history is retained, for how long, and whether it can be exported in bulk. If it cannot, record the key outcomes for each critical flow in your own runbook or reporting store.

Job logs and error detail

Step-level logs and error messages explain why a recipe failed on a given day, and they are often the fastest way to rebuild a broken edge case in the new platform. Treat them as separate from the package. Check whether the platform's own tooling lets you download logs and for what window. Where it does not, capture representative failure cases, the expected handling for each, and the alert rules that flagged them, so the rebuilt flow has the same behavior tests.

Asset types outside the package

The documented package covers recipes, connections, custom connectors, lookup tables, recipe functions, environment properties and optionally tags. Any other asset your team uses, such as projects settings, workspace-level configuration, or assets added after the documentation you are reading, is not guaranteed to be included. Build an inventory of every asset type in use in your workspace and mark each one as exported, exported with conditions, or documented manually. Ask Workato to confirm the list for your version.

Connection credentials and secrets

The package references connections but does not hand you working credentials. Passwords, API keys, OAuth tokens and the secrets behind on-prem agent connections must be re-entered or re-issued in the target platform, under accounts you control. Record which connection each flow uses, which account owns it, and which scopes it needs. Plan the credential handover with your security team so no secret is copied into a spreadsheet or a ticket during the move.

On-prem agent and network configuration

Workato's on-prem agent sits in your network and makes outbound connections to Workato over a TLS WebSocket tunnel without inbound firewall ports. The agent registration, its host, and the network rules that let it reach internal systems are infrastructure details that the recipe package does not describe. Document each agent, the systems it reaches, and the firewall rules that permit that traffic, so the replacement runtime can be placed on the same network path.

Ownership, permissions and audit trail

Who owns each recipe, who can edit it, and what changes were made over time are governance records. Folder permissions, sharing settings and change history do not travel with the JSON. Export the access model as a list, note which recipes have a named business owner, and confirm with Workato whether activity or audit logs can be retrieved for your contract. Keep this record with your change tickets so the new platform's access rules can be checked against it.

How a manifest turns a folder into a zip of JSON

The manifest defines what leaves Workato, and its scope is set by the folder you select. In Workato's recipe lifecycle management export, you build a manifest that points at a source folder. Workato packages the recipes in that folder and its subfolders as JSON, adds the dependent assets it finds, and produces a zip. The package can also contain connections, custom connectors, lookup tables, recipe functions, environment properties and, optionally, tags. Before you run the export, list the folders your recipes live in and confirm that each one is either inside the selected tree or intentionally excluded. Anything that sits outside that tree, or that a recipe references only indirectly, can be missed, so compare the zip contents against your recipe inventory before you treat it as complete.

Keep shared connections in the Home folder so they export from any source folder. Workato advises placing shared connections in the Home folder, which lets a manifest from a different source folder pick them up. If a connection sits in a project folder that your manifest does not select, recipes that depend on it may export without a clear link to the connection they need. Review where each shared connection lives and move any that a second team relies on before you build the manifest. Also note that exporting all projects in a workspace requires the create projects privilege, so confirm with your Workato administrator which account will run the export and whether that account holds this privilege.

Treat the zip as a structural specification, not a credential store. The JSON describes recipe logic, connector references and configuration, so it is the document you will rebuild from. Connection credentials are not the point of the package, and you should not expect to restore live authentication from it. Plan to recreate each connection with its own secrets in the target platform, and confirm with your security team how the zip is stored and who can open it, because it still reveals your process design, endpoints and field mappings.

Run a complete export in the right order

This sequence turns scattered Workato assets into one or more verified zip packages that together account for every recipe, connection, table and property you intend to keep. Each step depends on the one before it, so skipping the inventory or the shared connection move usually produces a package that looks complete but leaves assets out.

Inventory projects, folders and recipes
Start by listing every project, folder and recipe in the workspace scope you plan to export, and record which recipes are active, stopped or in test. Ask the workspace owner or integration lead to confirm the list, since they know which folders hold production logic and which hold retired work. The output is a written inventory with a recipe count per folder, which you will check against the package later. Do not start exporting until this list is agreed.
Move shared connections into the Home folder
Workato advises keeping shared connections in the Home folder so they can be exported from different source folders. Review each recipe in the inventory for connections that sit in another folder, and move those connections to Home before building any manifest. Confirm afterward that each recipe still resolves its connections, because a recipe that loses access to a connection will export without the dependency you expect. The output is a Home folder that holds every shared connection the exported recipes need.
Build one manifest per source folder or workspace scope
Create a manifest for each source folder, or for the whole workspace if you need every project. Workato automatically adds dependent assets from the selected folder and its subfolders, so choosing a parent folder captures its children. If you export all projects in a workspace, the user needs the create projects privilege, so confirm that with the workspace administrator before you begin. The output is a set of named manifests whose scopes match the inventory.
Select Include data on lookup tables that need rows
Workato exports only lookup table headers by default, so table rows are missing unless you select Include data for each table. Open each lookup table in the manifest that holds reference values your recipes depend on, and enable that option. Record the tables where rows matter, such as mappings, routing rules or code lists, because a schema-only export will not restore them. The output is a manifest where every row-dependent table is marked for data inclusion.
Add tags if your team uses them
Tags are optional in Workato's export, so decide whether your team uses them to classify recipes, owners or environments before you finalize the manifest. If tags carry ownership or lifecycle meaning, include them so the package keeps that context for the rebuild team. Note in your inventory which tags were included, so the reviewer can check them alongside the recipes. The output is a manifest whose optional tag selection matches your documented decision.
Download the zip package
Run each manifest and download the resulting zip. The package contains JSON representations of recipes, connections, custom connectors, lookup tables, recipe functions, environment properties and, if selected, tags. Save each file with its manifest name and the export date so it matches the inventory entry. The output is one zip per manifest, named and stored consistently.
Verify recipe counts and lookup table rows
Open each zip and compare the number of recipe JSON files with the recipe count you recorded in the inventory for the same scope. Then check each lookup table you marked for data, confirming that the row count matches what you expect from the source. Any mismatch means a folder, subfolder or table was missed, and you should correct the manifest and re-export before continuing. The output is a short verification record showing that counts match for every scope.
Confirm environment properties and custom connectors, then store under change control
Confirm that environment properties and custom connector files appear in the package, since a recipe can run in Workato yet fail to rebuild elsewhere if these are missing. Calculate a checksum for each zip and record it with the verification record. Store the packages, checksums and inventory in a repository under change control, with access limited to the team that owns the migration. The output is a controlled archive that can serve as the specification for rebuilding flows.

Using the package as the specification for a rebuild

Integration engineers can use the recipe JSON as a map of each flow before they open a canvas in the target platform. The export records each recipe's trigger, its ordered actions, and the data mappings that pass values from one step to the next, so an engineer can trace a value from its source field to its destination without reconstructing the flow from memory. The file is a faithful description of the logic at export time, so it is most useful when read alongside a current run history from the source system.

Triggers: Identify each entry point, such as a schedule, a webhook or a polling event, and its configuration.
Action sequence: Record the order of steps, including any branches, loops and error handling that change the path.
Data mappings: List which fields feed which downstream inputs, and note any transformations or formulas applied to them.
Connector references: Note which applications each step calls, so you can match them to components in the target platform.
Dependencies: Check which lookup tables, functions or custom connectors each recipe calls, because a flow that looks simple may depend on several assets.

Before you sign off a rebuilt flow, compare its outputs against the source recipe using the same test input and confirm that the mappings and branches match the JSON.

What to plan before the Workato contract ends

The export package is only one piece of leaving Workato. Export rights, the target platform's license, the on-prem agent and the parallel-run window all depend on each other, so decide them together before the renewal date.

Confirm export rights early

Exporting all projects in a workspace requires the create projects privilege, so confirm with your Workato account owner that the people running exports hold it. Ask for this in writing before renewal, because losing access to the account can end the export window. Map which folders and environments each team owns, so no recipe is left out of the inventory.

Schedule exports for each environment

Run a manifest export for every environment, including development, test and production, because each one can hold different recipes and connection settings. Record the export date, the source folder and whether lookup table rows were included. Keep each zip under version control so you have a dated copy after the contract ends.

Include lookup table data deliberately

Workato exports only lookup table headers by default, and rows are added only when Include data is selected for each table. Check every lookup table that holds business mappings or reference values, because a package without rows will rebuild flows that fail on first run. Store any sensitive table data under the same controls as your other production data.

Keep shared connections in Home

Workato advises keeping shared connections in the Home folder so they can be exported from different source folders. Recipes that depend on connections stored elsewhere may export without the connection context you need. Verify the dependency list in each package against the folder structure before you treat it as complete.

Choose the target and its license

Decide the target platform before rebuilding starts, and read its license for your use case. n8n is source-available under the Sustainable Use License, not OSI open source, and its .ee files need an Enterprise License. Windmill's prebuilt Community images include proprietary code that is free for internal use, while managed services or reselling need a commercial license. Ask legal to confirm both against your intended deployment.

Plan the on-prem agent shutdown

Workato's on-prem agent makes only outbound connections over a TLS WebSocket tunnel and needs no inbound firewall ports. Plan its shutdown as a change request: list the internal systems it reaches, identify the firewall rules and service accounts that exist only for it, and remove them after recipes are confirmed off the agent. Confirm the new platform's network path to each of those systems first.

Set a parallel-run window

Run rebuilt flows alongside the Workato originals for a fixed window, comparing outputs, error rates and downstream records. Agree the exit criteria and the window length with stakeholders in advance, and confirm the Workato contract end date covers it. Keep the original recipes paused rather than deleted until the parallel run passes.

Questions teams ask before exporting from Workato

Can our own team export Workato recipes without an outside partner?

Yes, in most cases an internal team can build the export itself, because Workato provides recipe lifecycle management exports from the product. The work is mostly administrative: creating a manifest for each folder, selecting the right assets and downloading the zip. The harder part is verification, because someone must confirm that every recipe, connection reference and lookup table in the package matches what runs in production. Teams with a small number of folders and an owner who knows each flow often manage this in-house. Teams with many interdependent recipes often bring in outside help for the inventory and rebuild plan, which is a separate decision from the export itself.

What makes an Workato export take longer or require more effort?

The effort follows the size and shape of the estate, not a single number. The main drivers are the count of recipes and projects, how many folders and subfolders a manifest pulls in, the number of custom connectors, the size of lookup tables where row data is included, and how many recipes depend on on-prem connections. Each custom connector and on-prem connection adds work during the rebuild because it needs a replacement path in the new platform. Shared connections kept in the Home folder simplify exports from several source folders. Ask your team to inventory these counts before requesting a quote.

What access do we need on the Workato side to run the export?

You need a workspace account with enough privilege to create and download manifests for the folders in scope. Workato documents that exporting all projects in a workspace requires the create projects privilege, so confirm that your administrator grants it before the work starts. Integration owners should also be available to review each exported recipe, since they know which flows are business critical and which are retired. Keep a record of who approved the package, because the zip becomes the inventory used later for the rebuild. Confirm the exact role names in your own workspace with your Workato administrator.

Does the Workato export include lookup table data by default?

No. By default, Workato exports only the lookup table headers, meaning the column structure without the rows. Table rows are included only when you select Include data for each table in the manifest. Teams often miss this during a migration, then discover that a rebuilt flow returns empty values because the reference data never came across. Review every lookup table individually, decide whether its rows are configuration or sensitive business data, and store any exported row data under the same access controls as the source. Confirm the row counts after import.

How do we handle connections that must be recreated after the export?

Connections typically do not carry their stored credentials into a new platform, so each one must be recreated and authorized by someone with the right access to the target system. Treat the export as the list of required connections, not as a way to move secrets. Map each connection to its replacement in the new runtime, record the owner of each target account, and plan on-prem connections separately because they depend on network paths and agent placement. Store new credentials in a secrets manager you control, and rotate any credential that was shared during the migration.

Can we use the exported package as the specification for rebuilding flows?

Yes, the zip is a practical starting point because it contains JSON representations of recipes, connections, custom connectors, lookup tables, recipe functions and environment properties, along with dependent assets pulled from the selected folder. Engineers can use it to list triggers, actions, data mappings and dependencies, then decide which flows to rebuild, retire or consolidate. It does not replace testing. Each rebuilt flow still needs test cases based on real inputs and expected outputs, and integration owners should sign off before cutover.

What should a rebuild quote include after the export is complete?

A useful quote lists the scope in writing before work starts: the folders and recipes covered, the target platform and edition, the custom connectors and on-prem connections to rebuild, the lookup tables and data to migrate, the test and sign-off process, and the cutover and rollback plan. It should also state what the client team must provide, such as access, owners and test accounts, and what happens to recipes that are retired rather than rebuilt. Ask whether the price covers hosting, backups and post-cutover support separately, because those costs recur. DeployOpen fixes scope, deliverables and timelines in writing before work begins.

What to ask for in a fixed-scope export and rebuild quote

The first thing to ask for is a written scope, because a fixed-scope engagement is only as precise as the inventory behind it. DeployOpen agrees scope, deliverables and timelines in writing before work starts, so the quote should name the export inventory: every recipe, connection, custom connector, lookup table, recipe function, environment property and tag in the folders you select, along with the dependent assets Workato adds automatically from subfolders. Ask whether the inventory will flag lookup tables exported with headers only, since table rows appear only when Include data is selected for each table. Also ask who confirms that the Home folder holds the shared connections and that the account used has the create projects privilege if all projects in the workspace are included.

The second thing to ask for is a verification checklist agreed before the rebuild starts. It should state how each recipe in the package is mapped to its target workflow, how test data and lookup rows are compared against the source, and who signs off each flow before it runs against production systems. Ask for a list of connections and on-prem dependencies as a separate deliverable, covering each application credential, each on-prem agent-reached system and the owner who can re-authorize it, because recipes cannot be rebuilt until those connections exist in the target. Confirm with your own team which internal endpoints are reachable from the target network, since that determines whether the on-prem access path needs its own work item.

Finally, ask how post-migration support is handled. Ongoing support, upgrades and continuous testing are available as a retainer, and it is separate from the fixed-scope work, so the quote should show both. Ask what happens if the export reveals recipes that were not in scope, and how changes are priced and approved. Your own decisions still drive the cost: the number of flows, the number of connections that need re-authorization and the amount of lookup data all change the scope, so confirm those figures in your environment before you sign.

How DeployOpen scopes and delivers a Workato exit

DeployOpen approaches a Workato export as the first step of a fixed-scope migration inside your own infrastructure. We treat the exported package as the inventory of recipes, connections and lookup data, then agree in writing what gets rebuilt, tested and handed over before any work starts.

How we scope

Review the manifests you plan to export and confirm which folders, subfolders and tags they cover
Confirm whether lookup tables need row data included, since headers are exported by default
Agree in writing which recipes, custom connectors and environment properties fall inside the engagement

How we build

Rebuild each exported recipe on the target platform, mapping connections and on-prem access to your internal systems
Test rebuilt flows against the behavior recorded in the JSON files, including lookup data and error paths
Configure the target runtime, access controls and secrets handling inside your own cloud accounts or data centers

How we hand over

Deliver a written inventory that maps every exported asset to its rebuilt counterpart or to a documented decision
Document connection setup, credential ownership and recreation steps so your team can run the flows without us
Provide test evidence and runbooks that your auditors or internal reviewers can read against your own requirements

How we support

Engagements are fixed-scope, and scope, deliverables and timelines are agreed before work begins
Ongoing support, platform upgrades and continuous testing are available as a retainer after handover
Ask for the written scope to show exactly which exported packages, environments and privileges are covered