Which should a code-first integration team choose, Workato or Windmill?
A code-first integration team should choose Workato when most of its work is covered by existing connectors, when business users need to build and maintain recipes, and when it would rather pay a vendor to run the cloud control plane, upgrades and support. Workato's on-prem agent handles private systems without inbound firewall rules, which is a real advantage for teams that cannot change their network posture. Choose Windmill when engineers would rather write scripts in Python, TypeScript, Go, SQL or Rust and compose them into flows, and when the whole runtime must stay in your own infrastructure. The decision turns on four questions: connector coverage, whether your engineers prefer code to recipes, where data is allowed to live, and who will operate the platform.
Start with connector coverage. List the applications your flows touch today and check whether Workato's catalog covers them natively. In Windmill, most integrations are code you write and own, so a system without a prebuilt connector means estimating the engineering effort to call its API, handle pagination, retries and credentials. Next, check how your team works. If engineers review changes in Git and want flows tested like software, Windmill's scripts and flows suit that workflow. If the people who maintain integrations are operations or business analysts, a recipe builder will usually be faster for them to use. Confirm with Windmill which Git sync and enterprise features your plan includes before you depend on them, since the pricing page lists full Git sync under Enterprise Edition.
The last two questions are about data and operations. Map where each flow's data is processed and stored, including logs and secrets, and ask Workato which regions and on-prem options apply to your contract. With Windmill you control hosting directly, but you also own patching, PostgreSQL backups, worker capacity and the upgrade path, so name a platform owner before choosing it. Run a short pilot with one production-like flow that touches a private system, and measure the engineering hours it takes, the access your security team must approve and how long a failed job takes to diagnose. Those numbers will tell you more than any feature list. Consider Windmill's Community Edition licensing carefully, because managed services or reselling need a commercial license.
Which scenarios favor Windmill and which favor Workato
This table maps common integration scenarios to the platform that usually fits them better. Read each row as a condition: the advantage holds only when the stated condition is true in your environment. The main takeaway is that Windmill suits code-first teams that want the runtime inside their own network, while Workato suits teams that want prebuilt SaaS connectors and vendor-run operations.
| Scenario | Better fit | Why and under what condition |
|---|---|---|
| Code-first engineering teams | Windmill | Scripts in Python, TypeScript, Go, SQL and Rust can be version-controlled and composed into flows. The advantage matters when engineers, not business analysts, own the logic. |
| Prebuilt Workato connectors for SaaS apps | Workato | Workato's connector catalog reduces build work for common SaaS apps. Windmill requires your team to write or maintain the integration code, so confirm that the apps you need are covered before choosing it. |
| Private systems reached only from inside a network | Windmill | Windmill workers can run next to internal systems in your own infrastructure. Workato's on-prem agent makes outbound-only connections to Workato's cloud, which also works, but it keeps the orchestration control plane outside your network. |
| Regulated data that must stay in the organization's infrastructure | Windmill | Self-hosting keeps workflow runs, logs and secrets on your servers. Confirm with your assessor which data classes are in scope, since Workato's agent still sends workflow data through its cloud service. |
| Teams without platform operations staff | Workato | Workato runs as a managed cloud service, so upgrades and hosting sit with the vendor. Self-hosted Windmill needs people to run PostgreSQL, workers, upgrades and backups, which is a recurring cost to plan for. |
| Need for vendor-run support | Workato | Workato's commercial agreement covers vendor support for the cloud service. Windmill support depends on the edition you buy, so ask Windmill which support terms apply to your Enterprise or Community deployment. |
| Need for SAML, SCIM and audit logs on a self-hosted runtime | Windmill | Windmill Enterprise adds SAML, SCIM and audit logs on your own infrastructure. The Community Edition does not include these, so budget for an Enterprise license if they are required. |
| Commercial use as a managed service or reseller | Workato | Windmill's prebuilt Community images are free for internal use only, and managed services or reselling need a commercial license. Confirm your licensing position before offering integrations to third parties. |
How Workato recipes map to Windmill scripts and flows
The main shift is that a Workato recipe is a configured graph built in a visual editor, while a Windmill script is ordinary code in Python, TypeScript, Go, SQL, Rust or another supported language, and a *flow* is the step-based graph that chains those scripts together. Integration teams that write code will find the logic easier to review, test and version, but they should expect to rewrite each recipe's steps as functions rather than click them together. Start by sorting every recipe into three buckets: the trigger and scheduling logic, the data mapping and error handling, and the connector calls. Triggers and schedules map to Windmill's flow triggers and schedules, mapping logic moves into the script body, and error handling becomes explicit try and retry code or flow-level error handling, which you should test against the failure cases your recipes already handle.
What carries over is the business logic and the orchestration pattern: which event starts the work, which fields are transformed, which branches run, and which records are retried or routed to a human. What does not carry over automatically is the connector logic that Workato supplies out of the box. Each HTTP call, authentication flow, pagination rule and field normalization your recipes rely on must be written or sourced again, and the credentials must move into Windmill resources or an external secret backend. Confirm Windmill's connector or resource coverage for each system you use, including on-premises databases, ERP modules and internal APIs, because a missing integration will turn into custom code. Treat the recipe export as the inventory and build a table that maps every recipe step to a script, a resource or a gap before estimating the rebuild.
Capability by capability: connectors, languages, governance and operations
This table compares how Workato and Windmill handle languages, execution, deployment, identity, audit and operations. Items marked Enterprise only apply to Windmill's paid self-hosted edition, and cells that say to confirm need a answer from Workato before you rely on them. Use the table to see where Windmill covers your needs and where you need Workato's managed features or your own replacements.
| Capability | Workato (commercial) | Windmill (open source) |
|---|---|---|
| Scripting languages | Recipes built from prebuilt connector steps. Confirm which custom code steps your plan supports. | Scripts in Python, TypeScript, Go, Bash, SQL, GraphQL, PowerShell, Rust and more, composed into flows. |
| Backend and workers | Managed cloud service. The on-prem agent makes outbound TLS WebSocket connections only. | Rust backend with stateless API servers and workers that pull jobs from a PostgreSQL queue. You run the workers. |
| Job sandboxing | Confirm with Workato how recipe execution is isolated and where it runs. | Jobs are sandboxed with nsjail. |
| Deployment method | Cloud service with an on-prem agent inside your network. | Self-hosted with Docker Compose or Kubernetes Helm charts. |
| External PostgreSQL | Not applicable. The database is operated by Workato. | Supports external databases such as AWS RDS, GCP Cloud SQL and Azure. You manage backups and upgrades. |
| SAML and SCIM | Confirm the identity options included in your Workato edition. | Enterprise Edition only. Community Edition does not include these. |
| Audit logs and external secrets | Confirm audit log scope and secret manager integrations in your contract. | Audit logs and external secret backends such as Vault and AWS Secrets Manager are Enterprise Edition only. |
| Git sync and autoscaling | Confirm how recipe versions are stored and promoted between environments. | Full Git sync and autoscaling are Enterprise Edition only. Community Edition is limited to 3 workspaces. |
| Prebuilt connectors and managed governance | Workato's prebuilt connector catalog and managed governance have no direct equivalent in Windmill. Plan to write or maintain the integrations you need as scripts. | Not applicable |
Where data runs, who operates it, and what the on-prem agent changes
Workato and Windmill differ less in features than in where the control plane and runtime sit. The cards below cover the network path, the operating burden, identity and the evidence each model produces, so you can map them to your own data residency and audit requirements.
Workato's cloud control plane and agent
Workato runs as a cloud service, and its on-prem agent sits inside your network to reach private systems. The agent makes only outbound connections to Workato over a TLS WebSocket tunnel and needs no inbound firewall ports. Check which parts of a recipe execute in Workato's cloud and which execute through the agent, because that determines where a given payload is processed and logged.
Outbound-only agent traffic
The agent's outbound-only design is attractive when inbound rules are restricted, but it still requires an outbound path to a cloud endpoint. If your policy forbids any outbound route from production segments to a SaaS control plane, the agent model does not fit and you should evaluate a self-hosted runtime. Ask Workato to confirm the endpoints, ports and proxy support in writing for your environment.
Windmill runs inside your boundary
With Windmill self-hosted, you deploy the API servers, workers and PostgreSQL database in your own accounts or data centers, using Docker Compose or Kubernetes Helm charts. Job data, script outputs and secrets then stay within your network and your backup scope. The trade-off is that you own uptime, patching, scaling and disaster recovery for every component.
Operating the database and workers
Windmill's workers pull jobs from a PostgreSQL queue, so the database is a critical dependency. Decide whether to run PostgreSQL yourself or use a managed service such as AWS RDS, GCP Cloud SQL or Azure, and document backup, restore and failover tests for it. Size workers with the README's rule of one worker per vCPU with 1 to 2 GB of RAM as a starting point, then validate against your own job profile.
Identity with SAML and SCIM
Windmill Enterprise adds SAML and SCIM, so user sign-in and provisioning can follow your identity provider rather than local accounts. Confirm which edition your identity design requires before you commit, since Community Edition is capped at 50 users. Map group membership to Windmill workspaces and groups so that access reviews can be performed in your identity system.
Audit evidence and what DeployOpen prepares
Audit logs are part of Windmill Enterprise, and Workato's governance features are part of its enterprise offering, so compare what each records about who ran which flow and who changed it. DeployOpen can plan, configure and document controls, logging and evidence collection for your compliance assessment. It does not issue audit reports, attestations or certifications; independent auditors and certification bodies do that work.
Which Windmill edition and license terms fit your organization
The Community Edition is the free self-hosted option that Windmill publishes with unlimited executions, as listed on its pricing page as of October 2026. Its limits are 3 workspaces, 50 users and 4 groups, also as of October 2026. Prebuilt Community images include proprietary code that Windmill makes free for internal use. That means your own staff running workflows inside your organization fall within the free terms, while anything beyond internal use does not.
- Execution limits: Executions are unlimited, so cost does not grow with run volume. Your recurring cost is infrastructure and staff time.
- Organizational caps: Confirm that 3 workspaces, 50 users and 4 groups cover your planned structure for the next two or three years, since exceeding them forces an upgrade decision.
- Enterprise controls absent: SAML, SCIM, audit logs, external secret backends, full Git sync, autoscaling and Prometheus and OpenTelemetry support are Enterprise features, so you must supply those controls yourself.
- Internal use only: Managed services or reselling require a commercial license, so a Community deployment that serves customers or partners is outside the free terms.
- Contractor access: Whether outside developers working for you count as internal use depends on your contracts and the license text, so ask counsel to review it.
Before you commit, check the current pricing page and the license text in the repository, because limits and terms can change between releases.",
The self-hosted Enterprise Edition removes the Community caps and adds the identity, audit and operations controls that regulated teams usually need. Windmill's pricing page lists it from $120 per month, priced by developers at $20 per month each, operators at $10 per month each and compute units, as of October 2026. Your bill therefore depends on headcount by role and on compute, so ask the vendor for a quote built from your actual user mix and worker footprint.
- Identity integration: SAML and SCIM let your identity provider handle sign-in and user provisioning, which helps access reviews and offboarding.
- Audit and secrets: Audit logs and external secret backends such as Vault and AWS Secrets Manager keep credentials and activity records under your own governance.
- Git and delivery: Full Git sync lets scripts and flows follow your normal review and version control process.
- Scale and observability: Autoscaling, Prometheus and OpenTelemetry support fit teams that already run monitoring stacks.
- Recurring cost: Seats and compute recur monthly, so model growth in developers and operators before you sign.
Ask the vendor which contract term, support level and renewal conditions apply, and whether the agreement covers your intended use.",
Windmill's source code, compiled without the enterprise feature flag, is available under AGPLv3 and Apache-2.0. This route avoids the prebuilt Community images and their proprietary components, but it moves packaging, patching and upgrade work onto your team. It suits organizations whose legal review prefers open licenses for every component they deploy, and that accept the build and maintenance effort.
- License split: The AGPLv3 obligations apply to modified network-accessible code, so have counsel review what you change and how users interact with it.
- Build pipeline: You own compilation, container images, signing and vulnerability scanning for every release you deploy.
- Upgrade discipline: Windmill ships releases frequently, and the latest release listed in October 2026 was v1.840.0, so plan a repeatable process for tracking and testing upgrades.
- Feature gaps: Enterprise features are gated by the feature flag, so you cannot get them from a source build without the Enterprise license.
- Operational ownership: Your team carries support, incident response and security patching that a vendor would otherwise share.
Before choosing this route, confirm with counsel and your engineering leads that you can staff the build and upgrade work for the life of the deployment.",
Licensing questions decide which tab fits, and they are not answered by this page alone. The facts that matter are the free internal-use terms for prebuilt images, the commercial license for managed services or reselling, and the AGPLv3 and Apache-2.0 terms for source builds. Each of these maps to a different business model, so write down your use case before you ask for a review.
- Internal users: Define who counts as internal, including employees, contractors, subsidiaries and offshore teams.
- Customer-facing use: Decide whether any workflow will run for customers, partners or a managed service you operate for others.
- Hosting provider: Confirm whether a third-party cloud or managed Kubernetes operator changes your position.
- Documentation: Keep the license texts, the version you deployed and the date you reviewed them in your change records.
- Renewal: Re-review the terms whenever you change edition, add user groups or move to a new major release.
Have counsel confirm each point in writing before rollout, because this page does not provide legal advice.
What drives the cost of Workato and of running Windmill
Workato bills for an enterprise subscription and usage, while Windmill's self-hosted cost is split between its licensing, the infrastructure you run and the people who operate it. Each card below names one component, who is paid, whether it is one-time or recurring, and what to request in a written quote.
Workato edition and usage fees
Workato is a commercial cloud service, so the subscription, edition and usage terms set the recurring licensing line. Ask the vendor to state which edition includes the on-prem agent, which usage metric applies to your recipes and whether environments, connectors and support are priced separately. Usage growth, number of recipes in production and the count of connected environments are the main drivers to model. Workato prices are not published here, so request them in writing.
Windmill Enterprise licensing
Windmill Enterprise is recurring. Its pricing page lists a base starting at $120 per month, with developers at $20 per month each, operators at $10 per month each and compute units, as of October 2026. Headcount of builders and operators and compute consumption therefore drive the bill. Confirm whether the base, seat counts and compute units are billed monthly, what a compute unit covers and whether your Enterprise features such as SAML, SCIM and audit logs are included at the tier you choose.
Worker and PostgreSQL infrastructure
Self-hosting Windmill moves compute and database costs onto your own accounts or data center. Windmill's README suggests one worker per vCPU with 1 to 2 GB of RAM, so script concurrency sets worker sizing. A managed PostgreSQL service such as AWS RDS, GCP Cloud SQL or Azure is supported and is billed by your cloud provider. Ask your cloud team to price the workers, database backups, high availability and egress, because these recur every month and grow with job volume.
One-time recipe rebuild effort
Rebuilding Workato recipes as Windmill scripts and flows is a one-time cost. Effort depends on the number of recipes, custom connectors, lookup tables and on-prem connections that must be reproduced in code. Workato's lifecycle exports can serve as the inventory, so ask for a per-recipe estimate that separates mapping, testing, cutover and parallel running. Treat the estimate as a written scope item, not a rate you can apply to every recipe.
Recurring platform operations
Someone must patch Windmill and its PostgreSQL database, rotate secrets, monitor workers and handle upgrades, which Windmill releases frequently. Operations labor is recurring and often the largest unseen line in a self-hosted comparison. Ask who owns on-call, how often upgrades are scheduled and whether Prometheus and OpenTelemetry monitoring is set up from the start. Staff time is paid internally or to a service provider, and it grows with the number of environments.
Support and implementation partner fees
Support is a separate decision on each side. Workato support is part of the commercial agreement, while Windmill support depends on the edition and any contract you sign. An implementation partner such as DeployOpen is quoted from a written fixed scope, and ongoing support or upgrades can be added as a retainer. Request the support tier, response terms, what is excluded and whether the quote covers hardening, backups and documentation.
What running Windmill asks of your platform team
Running Windmill moves operational work from the vendor to your team. Workato is a cloud service, so its operations, scaling and upgrades sit with Workato, and your side is limited to the on-prem agent inside your network. With Windmill, the API servers, workers, PostgreSQL database and sandboxing are yours to run. Start with sizing workers: Windmill's README gives a rule of thumb of one worker per vCPU with 1 to 2 GB of RAM. Use it as a starting point only, then measure your real job volume, job duration and memory peaks for the scripts you plan to run, especially any that process large files or call slow internal systems.
The database is the part most likely to need dedicated attention. Windmill uses PostgreSQL both for its state and as the job queue that workers pull from, so queue latency and database health affect every flow. Windmill supports external PostgreSQL services such as AWS RDS, GCP Cloud SQL and Azure, which can take over backups, patching and failover, but your team still owns sizing, connection limits, retention and restore testing. Confirm the exact supported versions and configuration with Windmill before you commit. Upgrades matter too: the project ships releases often, with v1.840.0 released on October 17, 2026 as the latest at the time of writing, so plan a regular, tested upgrade cadence for the Docker Compose or Helm deployment and check release notes for each version.
Security operations need explicit owners. Scripts run in sandboxes built with nsjail, and you should verify how that sandbox is configured in your deployment, including network egress, file access and resource limits. Secrets can be kept in Windmill or in external backends such as Vault or AWS Secrets Manager, which is a feature listed for Windmill Enterprise, so decide where credentials live before the first flow goes live. Monitoring is also your job: Enterprise adds Prometheus and OpenTelemetry support, and you should alert on failed jobs, queue backlog and worker health. Staffing for this needs platform engineers comfortable with Kubernetes or Docker, PostgreSQL administration, Linux networking, and at least one developer who can write and review Python or TypeScript integration code.
How a move from Workato to Windmill proceeds
The sequence turns a Workato estate into a tested set of Windmill scripts and flows, with workers placed beside the internal systems they call, and a cutover that happens only after parallel runs match. Each step ends with a check you can review before the next one starts.
Export a recipe inventory from Workato
The integration lead, with an administrator who holds the privilege to export, uses Workato's recipe lifecycle management to build a manifest and download the zip of recipe and dependency JSON files. Store the package under version control so it becomes the specification for the rebuild. Before relying on it, confirm with Workato's documentation what the export includes, especially how lookup table data, connection references and environment-specific settings are handled. Done when every production recipe, its dependencies and its owner appear in one reviewed inventory.
Classify recipes by connector and on-prem dependency
Group the inventory by the applications each recipe touches and mark every recipe that reaches a system only the on-prem agent can see. Note which recipes use triggers, scheduled runs or webhooks, because those need an equivalent entry point in Windmill. Assign each group a rebuild order based on business criticality and the number of internal systems involved. Done when each recipe has a target category, an owner and a known list of credentials that must be recreated in Windmill's secret handling.
Stand up a Windmill test environment
The platform team deploys Windmill with Docker Compose or the Kubernetes Helm charts documented in its repository, using an external PostgreSQL database if your standards require one. Decide between Community and Enterprise Edition at this stage, since SAML, SCIM, audit logs, external secret backends and full Git sync are Enterprise features, and confirm the current Community limits on the pricing page. Done when a test workspace runs a trivial script end to end, the worker count matches the README's guidance of roughly one worker per vCPU, and the license decision is recorded.
Rebuild priority flows as scripts and flows with tests
Developers rewrite the highest-priority recipes as Windmill scripts in Python, TypeScript or another supported language, then compose them into flows. Keep each script small, store it in Git, and write tests that replay representative inputs from the exported recipe data. Map each Workato connector action to an API call or a shared library function, and document any step that has no direct equivalent. Done when each rebuilt flow passes its tests against sanitized sample payloads and a reviewer has signed off on the mapping.
Connect internal systems through workers placed next to them
Place Windmill workers in the network segments that can reach the internal databases, APIs and file shares the flows need, so those connections stay inside your perimeter. Store credentials in the secret backend your standards require, and restrict which workers can run which scripts. Confirm in the Windmill documentation how job sandboxing and worker groups apply to your setup. Done when each on-prem dependency identified in step two is reached from a worker in its intended segment, and a connectivity test is recorded for each one.
Run in parallel and cut over
Run the Windmill flows alongside the live Workato recipes for an agreed observation window, comparing outputs, error rates and downstream records for the same inputs. Investigate every difference and fix it in Windmill before any traffic moves. Switch triggers recipe by recipe, keep the Workato recipe disabled but available for rollback, and retire it only after the owner confirms. Done when every migrated flow has a documented cutover decision, a rollback path and an owner's acceptance.
What buyers ask before moving from Workato to Windmill
How much does moving from Workato to Windmill cost?
The cost has four parts: the Windmill subscription or none if you stay on Community Edition, the infrastructure you run Windmill on, the one-time rebuild of recipes as scripts and flows, and the ongoing platform operations and support. Windmill's pricing page lists a free self-hosted Community Edition with unlimited executions, limited to 3 workspaces, 50 users and 4 groups, and its 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, as of October 2026. Workato's fees are quoted by Workato, so ask Workato for its edition and usage pricing in writing. Ask Windmill to confirm current Enterprise pricing and what compute units cost for your expected load.
How long does a Workato to Windmill migration take?
Duration depends on the number of recipes, the connectors each one uses, how many depend on on-prem connections, and how much test coverage exists to prove parity. Recipes with simple triggers and well-known APIs move faster than recipes that call internal systems through the on-prem agent, which must be replaced with workers placed on the same network. Export the recipe inventory first, then group recipes by complexity and dependency so the team can estimate effort per group. Ask any implementation partner for a fixed-scope plan with milestones written before work starts, and confirm the timeline against your own recipe inventory rather than a generic figure.
What skills does the team need for this move?
The work needs three groups of people. Integration engineers who write Python, TypeScript or SQL will rebuild recipes as scripts and flows. Platform operators will run the Docker Compose or Kubernetes deployment, the PostgreSQL database and the workers. Security reviewers will check secrets handling, network paths, sandboxing and access roles before production use. Windmill's backend is written in Rust and jobs are sandboxed with nsjail, so reviewers should read those design notes in the README and confirm how your own policies apply.
Can our own team migrate Workato recipes to Windmill without outside help?
Yes, a team with code-writing integration engineers and platform operators can do the migration in-house, provided it has time and capacity. Start with the Windmill GitHub repository and its self-hosting documentation to stand up a test environment, then rebuild a few low-risk recipes to learn the patterns. Outside help is most useful for the on-prem connections, the security review and the cutover plan. DeployOpen plans, implements and hardens self-hosted platforms in your own infrastructure under a fixed-scope written agreement, and offers retainers for ongoing support and upgrades.
Does Windmill Community Edition include SSO and audit logs?
No, SAML and SCIM, audit logs, external secret backends such as Vault and AWS Secrets Manager, full Git sync, autoscaling, and Prometheus and OpenTelemetry support are listed on Windmill's pricing page as Enterprise Edition features. Community Edition is free for self-hosting with limits on workspaces, users and groups. If your audit or SSO requirements are mandatory, plan for Enterprise Edition and confirm the feature list with Windmill before you commit. Also confirm whether the Community images you plan to use include proprietary code, which Windmill describes as free for internal use only.
Can Windmill run in an air-gapped network?
Windmill can be self-hosted with Docker Compose or Kubernetes Helm charts and can use external PostgreSQL databases such as AWS RDS, GCP Cloud SQL and Azure, so the runtime can sit entirely inside your network. Because Workato's on-prem agent relies on an outbound TLS WebSocket tunnel to Workato, an air-gapped design removes that dependency, but you must still plan offline image delivery, package and connector sources, updates and license handling. Ask Windmill to confirm the offline installation steps and licensing terms for air-gapped Enterprise deployments, and test them in an isolated environment before you rely on them.
What should we request from Windmill and Workato before we decide?
Request a written edition comparison and current pricing from Windmill, including compute unit rates, and a statement of which images contain proprietary code and the terms for internal use. From Workato, request the current edition and usage fees, the export and recipe lifecycle options, and the terms for on-prem agent use and data retention on exit. Ask both vendors to confirm support windows, upgrade paths and any restrictions on running their software for third parties, so the decision rests on documented terms.
How DeployOpen helps evaluate, implement and migrate to Windmill
DeployOpen is a Chainscore Labs company that plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For Workato vs Windmill, the work starts with a written scope that decides which recipes move, which Windmill edition fits, and where the workers run.
How we scope
- Inventory the Workato recipes, connectors and on-prem connections that must keep running
- Confirm which Windmill edition, Community or Enterprise, covers your SSO, audit and Git sync needs
- Agree deliverables, timelines and responsibilities in writing before any work starts
How we build
- Rebuild priority flows as Windmill scripts and flows in Python or TypeScript, with tests
- Deploy Windmill with Docker Compose or Kubernetes Helm charts on your external PostgreSQL
- Size workers next to internal systems and check sandboxing and secret handling before go-live
How we hand over
- Document architecture, runbooks, backup and restore steps, and worker sizing decisions
- Provide a parity checklist that maps each Workato recipe to its Windmill replacement
- Deliver knowledge transfer so your engineers can version, review and deploy flows themselves
How we support
- Plan Windmill upgrades against each release, reviewing changes before they reach production
- Run security testing of integrations and the Windmill deployment as part of ongoing work
- Offer ongoing support, upgrades and continuous testing as a retainer after handover
