Migrate from Workato to Windmill

Migrate from Workato to Windmill: what the move involves

The main work in this move is rebuilding Workato recipes as Windmill scripts and flows, because a Workato export cannot be loaded into Windmill as-is. The effort and risk depend on three things you can measure before you start: the number of recipes in production, the mix of connectors they use, and how many of them reach systems that sit behind your firewall. A team with a few dozen simple recipes against SaaS APIs faces a very different project from one with hundreds of recipes that call internal databases through the on-prem agent. Start by counting and classifying recipes, not by choosing a tool setup. In most organizations, internal engineers do this work, often with an implementation partner for the platform build, the worker placement and the parts that touch production credentials. The Workato lifecycle exports are JSON packages that describe each recipe, its triggers, actions and dependencies. Treat those packages as the specification for what each recipe must do, including error handling and the data it reads and writes, and then write the equivalent Python or TypeScript scripts. Expect to recreate every connection and secret in Windmill, because the exported logic does not carry working credentials. Ask the partner to state in writing how they will verify parity for each recipe.

Running Windmill inside your network is a separate decision from the code rewrite. Windmill workers pull jobs from a PostgreSQL queue, so placing them next to internal systems means deciding where that database runs, whether you use an external managed PostgreSQL service, and how workers are sized. Windmill's README gives a rule of thumb of one worker per vCPU with 1 to 2 GB of RAM, which is a starting point for capacity planning, not a guarantee. Decide early whether you need Enterprise features such as SAML and SCIM, audit logs, external secret backends and full Git sync, because these shape the identity, secrets and change-control design. Confirm current Community Edition limits and the Enterprise price with Windmill before you budget, since both change over time.

Which Workato capabilities map to Windmill, and which need rework

This table maps each Workato capability that integration teams rely on to its closest Windmill equivalent and flags whether the move is clean, needs rework, or is a gap. Read the middle column as the target and the last column as the effort to plan for, and confirm any Enterprise-only or unverified item with Windmill before you commit to a design.

Workato capability	Windmill equivalent	Migration note
Recipes and steps	Python or TypeScript scripts composed into flows	Needs rework: each recipe step is rewritten as code, and branching and error handling must be rebuilt explicitly
Connectors	Scripts calling internal or third-party APIs, plus community integrations where available	Needs rework: confirm which prebuilt connectors exist for your SaaS apps and budget for custom scripts for the rest
On-prem agent	Self-hosted workers running inside your network, next to internal systems	Clean in principle: workers pull jobs from PostgreSQL, so confirm your network rules allow the worker to reach each internal system
Lookup tables	Data stores you choose, such as PostgreSQL tables	Needs rework: export the data and define the schema and access rules yourself
Role-based access and SSO	SAML and SCIM in Windmill Enterprise	Enterprise only: confirm the role model maps to your groups before planning the cutover
Audit logs	Audit logs in Windmill Enterprise	Enterprise only: confirm the log fields and retention meet your evidence needs with Windmill
Environments and version control	Full Git sync in Windmill Enterprise	Enterprise only: without it, promotion between environments is a manual process you must document
Recipe lifecycle packages	Code stored and reviewed in Git repositories	Needs rework: use the exported packages as the specification, since they do not convert automatically

What data and integrations move, and what you rebuild

Workato does not hand over a runnable copy of your automations. Recipe JSON from its lifecycle management export becomes the specification, while credentials, on-prem connections and triggers are rebuilt in Windmill. Confirm the export scope in your own tenant before estimating the rebuild.

Recipe JSON as the specification

The recipe JSON packages produced by Workato's export describe each recipe's steps, triggers, actions and dependencies. Treat them as the inventory and the functional specification, not as an importable workflow. Windmill has no direct recipe importer, so each recipe is rewritten as a script or flow in Python or TypeScript. Check the export contents in your tenant, list which recipes and dependencies it covers, and record any recipe the package does not capture.

Lookup table data

Lookup tables hold reference values that recipes read at runtime, such as routing codes, currency maps or account mappings. Confirm whether your export includes lookup table data or only the recipes that reference it. Load the data into Windmill as a versioned resource, a database table in PostgreSQL or a file in your Git repository, and decide who owns updates. Without a clear owner, lookup values drift from the source system.

Connection credentials are recreated

Connection credentials do not move with recipe exports. Each connection to a SaaS application, database or API must be created again in Windmill with a service account scoped to the minimum permissions the script needs. On Windmill Enterprise, store those secrets in an external secret backend such as Vault or AWS Secrets Manager instead of workspace variables. Record each connection's owner and rotation schedule as you rebuild it.

On-prem connections and worker placement

Workato reaches private systems through its on-prem agent, which makes outbound TLS connections to the cloud service. In Windmill, the equivalent is a worker deployed inside the network segment that can reach the internal system. Each worker runs jobs pulled from the PostgreSQL queue, so place workers close to databases and internal APIs and size them with the vendor's rule of one worker per vCPU with 1 to 2 GB of RAM. Confirm the firewall rules you need for each segment.

Webhooks, triggers and schedules

Recipe triggers fall into three groups: incoming webhooks, polling triggers and scheduled jobs. In Windmill, webhooks map to HTTP-triggered scripts or flows, schedules map to cron-based triggers, and polling becomes a scheduled script that tracks its last-seen cursor. Recreate each trigger with its endpoint URL, authentication and retry behavior, then run old and new triggers in parallel to confirm that no event is lost or processed twice during cutover.

The migration sequence from inventory to decommission

This sequence moves Workato recipes into Windmill one at a time, proving each rebuild against live results before any cutover, so the team can retire Workato with a documented record of what changed and why.

Inventory every recipe from the lifecycle export
Start from the recipe lifecycle management package exported from Workato and list every recipe with its owner, trigger type, connectors, on-prem connections, lookup tables and downstream consumers. The integration lead and each business owner confirm the list. The step is done when every recipe has a named owner and a status of keep, rebuild, merge or retire, and the inventory is signed off.
Pilot one low-risk recipe in Windmill Community
Choose a recipe with a read-only or low-impact action, such as a scheduled report or a notification, and rebuild it as a Windmill script composed into a flow. Run a Community Edition instance, deploy a worker next to the internal system it calls, and store credentials in Windmill's resource settings. The pilot report records the code, the runtime settings, the test inputs and any connector gaps you found.
Run a parallel reconciliation with Workato live
Keep the original Workato recipe running while the Windmill flow processes the same inputs in a non-production or shadow mode. Compare outputs, error handling, timing and side effects for an agreed observation period set by the owner. The reconciliation log lists each difference, its root cause and the fix, and the owner accepts the rebuild only when the differences are explained.
Confirm edition and access controls before production
Decide whether the workload needs Windmill Enterprise features such as SAML and SCIM, audit logs, external secret backends, full Git sync or autoscaling. Confirm the license terms for your use with Windmill, because prebuilt Community images include proprietary code. Ask your security team to review secrets handling and access. The decision record names the edition, the controls and the evidence each one produces.
Cut over each recipe with a rollback path
Switch one recipe at a time from Workato to Windmill, starting with the lowest-risk items from the pilot. Each cutover follows a runbook that names the trigger change, the credential change, the monitoring check and the rollback steps, including how to re-enable the Workato recipe. The runbook is closed for a recipe only after the owner confirms the production behavior matches the reconciled outputs.
Decommission Workato after the agreed period
After every recipe is cut over or formally retired and the agreed post-cutover period ends, turn off the Workato recipes, revoke the on-prem agent and its connections, and remove stored credentials from Workato. Export a final copy of the recipe packages for records. The decommission record lists each recipe with its final status, the revocations completed and the date the agent was removed.

Community or Enterprise Edition: choosing the license for this migration

The Community Edition is the free self-hosted tier of Windmill. According to Windmill's pricing page as of October 2026, it has unlimited executions and is limited to 3 workspaces, 50 users and 4 groups. For many integration teams, that is enough to rebuild a set of Workato recipes in one or two workspaces and run them on their own infrastructure without a subscription.

Execution volume: The listed limits do not cap executions, so volume is governed by your own worker capacity rather than a metered plan.
Workspace and group limits: Map your intended teams and environments (for example, development, test and production) to the 3 workspaces before you commit to this tier.
User limit: The 50-user cap covers the people who build or operate flows in the platform, which is a smaller group than all users of the downstream business applications.
Image licensing: Prebuilt Community images include proprietary code that is free for internal use. Managed services or reselling require a commercial license.
Costs that remain: Hosting, PostgreSQL, worker capacity and your own operations staff are still your responsibility.

Confirm the current limits and image terms on the pricing page before you plan the rollout, and ask legal to review the internal-use wording if you plan to offer flows to customers.

What drives migration cost and duration

This table lists the factors that change the effort and cost of moving Workato recipes to Windmill, with a note on how to keep each one under control. Read it as a checklist for scoping: each row is a question to answer in your own inventory before asking for a written quote. Most of the cost sits in staff time and rebuild work, and the Windmill license is only one line among several.

Driver	Why it changes cost or effort	How to keep it down
Recipe count and complexity	Each recipe is rebuilt as a Windmill script or flow, so branching logic, error handling and loops add rebuild and test time.	Export the recipe inventory first, retire unused recipes, and group similar recipes into shared Windmill scripts.
Connector coverage gaps	Where Windmill has no ready-made integration for a Workato connector, someone must write and maintain custom code against the vendor API.	Map every connector before scoping, and confirm available libraries or API access for each gap with the target system owner.
Number of on-prem connections	Each internal system needs a worker with network access, plus credentials stored in a secrets backend and tested from that network.	Consolidate workers by network zone and test connectivity early in a pilot rather than at cutover.
Number of environments	Development, test and production workspaces each need their own configuration, secrets and Git-based promotion process.	Agree on a promotion model with Git sync before rebuilding, and keep the number of environments to what the change process requires.
Compliance evidence needs	Audit logs, access reviews, change records and SSO or SCIM provisioning must be shown to assessors, which adds design and documentation work.	Ask which evidence your assessor expects, then confirm which controls the Community Edition provides and which need Enterprise features.
Team coding skills	Scripts are written in Python, TypeScript and other languages, so staff without these skills need training or support, while those who have them move faster.	Pair Workato builders with developers during rebuild, and set coding standards and reviews before work begins.
Enterprise licensing scope	Windmill Enterprise pricing is based on developer seats, operator seats and compute units, so the number of people and workers drives the recurring license line.	Count who needs build rights versus run rights, size workers against the one worker per vCPU guidance, and request a quote for each seat type.
Parallel run length	Running Workato and Windmill side by side keeps two platforms licensed and operated, and the overlap period is set by your own testing and sign-off.	Define exit criteria for each flow, cut over in groups, and retire Workato recipes as each group passes testing.

What usually goes wrong when recipes become code

Rebuilding Workato recipes as Windmill scripts and flows moves logic, credentials and runtime into your own hands. Most failures come from assumptions that were invisible in the recipe builder, such as retry behavior, secret handling and capacity. The cards below name each risk and the check that prevents it.

Silent retry and error differences

Workato recipes handle retries, error branches and timeouts in ways that are easy to miss when you read them as a visual flow. A rebuilt Windmill script may retry, fail or continue differently without any warning. Before cutover, list every recipe's error path and test each one with a failing downstream system. Confirm how Windmill flows handle step failure and retries in your version, and write those rules down as part of the specification.

Credentials copied, not rotated

The fastest rebuild copies API keys and passwords from Workato connections into Windmill resources. That leaves the same secrets valid in two systems and keeps any leaked value live after the migration. Issue new credentials for each system, store them in Windmill resources or an external secret backend, and retire the Workato copies on a set date. Check which secret backends your edition supports before you decide where secrets live.

Workers sized by guesswork

Windmill's README gives one worker per vCPU with 1 to 2 GB of RAM as a rule of thumb. Treat it as a starting point only, because script memory, polling frequency and the jobs your slowest integrations hold open all change the real load. Run representative recipes at expected volume, watch queue depth and memory, and scale workers from those measurements. Ask your platform team which node sizes and network zones the workers need to reach internal systems.

Community limits reached unexpectedly

The Community Edition is free to self-host, but it caps workspaces, users and groups. Teams often discover the limit only after a second business unit or a larger developer group starts using the instance. Count workspaces, users and groups in the migration plan, including the people who will only review or operate flows. Compare the counts with the Community limits on the pricing page before you choose an edition, and record the decision in writing.

Cutover without parallel runs

Switching a live integration from Workato to Windmill in one step leaves no evidence that the new scripts produce the same records. Run both platforms side by side for a defined period, comparing outputs, error counts and timing for each flow. Keep Workato active in read-only or shadow mode for the flows you cannot pause. Define the exit criteria in writing before the parallel run starts, and do not decommission the Workato recipe until those criteria are met.

Scripts outside version control

Scripts edited directly in the Windmill interface can drift from what anyone reviewed, and an untracked change can break a flow with no record of who made it. Windmill Enterprise includes full Git sync, while the Community Edition setup should be checked for how you track changes. Store every script and flow in a repository, require review for changes, and deploy from the repository rather than the editor. Confirm which Git sync features your edition provides before you rely on them.

How the migration changes by starting point

A small integration team with a modest recipe count usually starts on the free Community Edition, which the pricing page lists with unlimited executions and limits of 3 workspaces, 50 users and 4 groups as of October 2026. The migration is mostly a rebuild exercise. Because the team owns every script it writes, the work is planned around recipes in priority order rather than around licensing.

Inventory first: List each Workato recipe, its trigger, its connections and its owner, then mark the ones that still run business-critical processes.
Rebuild as scripts: Write each connector call as a Windmill script in Python or TypeScript, and compose the steps into a flow.
Keep connections in variables: Store credentials as Windmill resources so they are not copied into code.
Run in parallel: Keep the Workato recipe active until the Windmill flow produces matching output for the same inputs.

Before relying on Community Edition, confirm that its limits, and the license terms for prebuilt images, fit how your team deploys and shares the platform internally.

Questions teams ask before migrating Workato to Windmill

How much effort does a Workato to Windmill migration take, and what drives it?

The effort depends mostly on how many recipes you run, how many connectors and on-prem connections they use, and how much business logic lives in lookup tables and error handling. Each recipe becomes a Windmill script or flow that your team writes and tests, so a recipe with many steps, branches and retries takes longer than a simple sync. Connector count matters too, because each external system needs a reviewed code path, credentials and tests. Ask any partner to break the estimate down by recipe category and by connector, and to show how parallel runs will be handled before the old recipes are switched off.

Can Workato export files be imported directly into Windmill?

No. Workato's lifecycle management exports are JSON descriptions of recipes and their dependencies, and Windmill does not read them as runnable flows. Treat the package as the specification: it shows triggers, actions, field mappings and dependencies that you rebuild as Python or TypeScript scripts and flows in Windmill. The export is still valuable because it gives you a complete inventory to test against, which reduces the risk of forgetting a recipe that runs quietly in the background.

Can our team migrate from Workato without outside help?

Yes, if you have engineers who can write Python or TypeScript, maintain code in Git and operate a PostgreSQL-backed service. The work requires time for rebuilding recipes, writing tests, configuring workers and running parallel executions against real systems. Teams that lack staff for those tasks, or that need a fixed delivery date, often prefer a written, fixed-scope engagement that defines deliverables and acceptance tests in advance. DeployOpen plans, implements and documents this kind of work inside your infrastructure, but the scope and cost come from a written proposal after review of your recipe inventory.

How long does the migration take?

Duration depends on your recipe inventory, the number of systems each recipe touches, how many recipes must run in parallel with Workato, and how quickly your security team approves worker placement and secrets handling. A small set of low-risk syncs can move quickly, while a large estate with on-prem systems needs a phased plan. No timeline should be accepted until it is written into a scope that lists recipes by wave, acceptance criteria and parallel-run periods. Ask your provider for that scope before committing to a date.

Which Windmill edition should we start with?

Start with the edition that matches your governance needs at the time you deploy. Windmill's pricing page lists a free self-hosted Community Edition with unlimited executions, limited to 3 workspaces, 50 users and 4 groups, as of October 2026. The self-hosted Enterprise Edition starts at $120 per month, priced by developers at $20 per month each, operators at $10 per month each and compute units, according to Windmill's pricing page as of October 2026. Enterprise adds SAML and SCIM, audit logs, external secret backends, full Git sync, autoscaling and Prometheus and OpenTelemetry support. Confirm current pricing and the license terms for your use, since Community images include proprietary code that is free for internal use only.

What happens to credentials and on-prem connections during the move?

Credentials do not transfer with the recipe export, so each connection must be recreated in Windmill and tested against its target system. Store secrets in Windmill's secret handling or, with Enterprise, in an external backend such as Vault or AWS Secrets Manager, and limit who can read them. On-prem connections need a different plan, because Workato's agent makes outbound connections to Workato, while a self-hosted Windmill worker runs inside your network and reaches internal systems directly. Confirm network routes, service accounts and rotation policies with your security team before the first production run.

How DeployOpen scopes and runs a Workato to Windmill migration

DeployOpen is a Chainscore Labs company that plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure, whether that is a cloud account, a data center or an air-gapped network. For a Workato to Windmill move, that means the Windmill workers, the PostgreSQL queue and any external database, the network paths to internal systems, and the connections and secrets the scripts depend on all run where your team decides. DeployOpen does not resell Windmill, is not a Windmill partner, and does not issue audit reports or certifications. Independent assessors handle those, and DeployOpen prepares the systems and evidence they review.

Most engagements are fixed-scope: the recipes in scope, the flows to be rebuilt, the environments, the deliverables and the timeline are agreed in writing before work starts. Ask for the written scope to name the recipe inventory you are migrating from, which Windmill edition is in use, who owns the Enterprise features such as SAML, SCIM and Git sync if you choose them, and what acceptance testing looks like for each flow. DeployOpen does not publish a price list. A quote follows from the written scope, so the inputs that move it are the number of flows, the number of distinct connectors and internal systems, the hosting and high availability design, and the testing and cutover work.

Ongoing support, version upgrades and continuous security testing are available as retainers after the migration closes. This matters for Windmill because its releases are frequent, and each upgrade of the self-hosted stack needs regression checks against your scripts. Before you sign, confirm in the scope who applies upgrades, how rollbacks are handled, and who is on call for worker failures. Any retainer terms, response expectations and service levels should appear in the signed agreement, not in marketing material.

Migrate from Workato to Windmill