Migrate from Workato to Apache Camel

Migrate from Workato to Apache Camel: what the move involves

Moving from Workato to Apache Camel is a developer-led rebuild: each recipe is redesigned as a Camel route, with the exported package used as the specification. It is not a data import, because Workato recipes are not converted into Camel code by any tool you can run in one step. The work is usually done by Java integration developers who already understand the systems on both ends, supported by an architect who decides how routes are grouped, versioned and deployed. Plan for the people first, then the platform. Confirm with your own team whether you have enough Java and integration engineers to own routes after go-live, because that ownership is the recurring cost that matters most.

The licensing is simpler than most alternatives. Apache Camel is licensed under Apache-2.0 and maintained by the Apache Software Foundation, so there is no source-available restriction on internal or commercial use of the framework itself. The release choice matters more. Camel 4.22.1 is an LTS release supporting Java 17, 21 and 25, with end of life in August 2027, and Camel 4.18.5 is an LTS release with end of life in February 2027. Camel 4.23.0 is the latest standard, non-LTS release. LTS releases receive bug and security fixes for up to one year, so pick the line that matches your upgrade cadence and check the Apache Camel download page before you freeze a version. Commercial support from Red Hat is optional and covers Spring Boot and Quarkus runtimes only.

Effort depends on recipe count, connector mix and on-prem dependencies, and no figure in this guide replaces your own inventory. Recipes that call common REST, JDBC or Kafka endpoints usually map cleanly to Camel components. Recipes that reach private systems through the Workato on-prem agent need a different plan: you must decide how those systems will be reached from your own network, which credentials and certificates the routes will hold, and who rotates them. Start by counting recipes, grouping them by connector and by on-prem dependency, and asking your partner or internal team to estimate each group separately. Ask for that breakdown in writing before agreeing a scope.

Which Workato capabilities map to Camel and which need rework

This table maps the main Workato recipe building blocks to their Apache Camel equivalents and labels each as clean, needs rework or gap. Read it as a planning aid: a clean mapping still needs a check of component coverage for each connector you use. The main takeaway is that Camel covers the integration logic well, but the low-code editing that business users do in Workato has no direct Camel counterpart.

Workato capability	Camel equivalent	Status
Recipe triggers (polling, webhooks, scheduled)	Camel routes starting from from() endpoints such as timer, HTTP or polling components	Clean
Actions against SaaS and database connectors	Camel components for Kafka, REST, JDBC, AWS, Azure, GCP and Salesforce, among 350+ connectors	Clean, confirm each component
Connector coverage for less common apps	Check the Camel component catalog; some apps may need a custom component or an HTTP call	Needs rework
Lookup tables	Externalized data in a database table, property file or Camel bean, loaded through JDBC or a configuration source	Needs rework
On-prem connections and private networks	Routes deployed inside your network on Spring Boot, Quarkus or Kubernetes, with credentials held in your secrets store	Needs rework
Error handling and retries	Camel error handler, onException and redelivery policies written in code	Needs rework
Scheduling	Timer components, cron expressions or Kubernetes scheduling through Camel K	Clean
Visual recipe editing by business users	Kaoto visual designer with code review in Git; Camel has no low-code recipe runtime	Gap

What to export from Workato and how the package becomes the spec

The recipe lifecycle management export is the starting inventory for this migration. Each card covers one item the export gives you, one item you must rebuild by hand, or one item that sits outside the package entirely.

Build the export manifest

Recipe lifecycle management starts with a manifest that lists the recipes and dependencies to include. Build it in the Workato environment that holds production logic, not a sandbox copy, so the inventory matches what runs today. Record which folders, projects and recipe versions are included, and compare the count against your own list of live flows. Anything missing from the manifest becomes a gap in the Camel routes, so reconcile it before any rebuild work starts.

Read the zip as the specification

The export is a zip of JSON files describing recipes and their dependency files. Treat these JSON files as the specification for each route: trigger, actions, data mappings, error handling and conditional logic. Your developers should write a short mapping note per recipe that points to the JSON section it came from. This keeps the Camel routes traceable back to the original logic when someone asks why a step behaves a certain way.

Include lookup table data

Lookup tables used by recipes are part of the export, so the mapping values that drive routing and field translation carry over with the package. Confirm the row counts and key columns after import, since a truncated or stale table will silently change output. Decide whether each lookup becomes a configuration file, a database table or an external service in the Camel deployment, and record that decision with its owner.

Replace credentials and connection IDs

Exported recipes refer to connections by identifier, and the secrets behind those connections never leave Workato. Each connection must be recreated as a credential in your own secret store and referenced from the Camel route by name. Map every old connection ID to its new reference in a table, and confirm that no secret value appears in the JSON, the manifest or the repository. Rotate credentials that were shared across recipes.

Rebuild on-prem connection endpoints

Recipes that reach private systems through the Workato on-prem agent depend on agent-side connection definitions. The export shows which recipes use them, but the hostnames, ports, certificates and network paths belong to your environment. Document each endpoint, confirm which network zone it sits in, and plan how Camel routes on Spring Boot, Quarkus or Kubernetes will reach it without the agent. Test each endpoint from the runtime network before cutover.

Confirm environment-specific values

Recipes often hard-code environment values such as base URLs, tenant identifiers, queue names and feature switches. The export carries these values from the source environment, so they may point at development or staging systems. List every value that differs by environment and move it into externalized configuration per environment. Check each value against the target system owner before the first production run.

Data already in downstream systems

The export contains workflow logic and lookup data, not the records that recipes have already written to CRMs, ERPs, databases or file stores. Migrating that data, or reconciling in-flight messages and retries that Workato still holds, is a separate project owned by the teams that run those systems. Agree the cutover point in writing, document which systems hold partial state, and assign an owner for each reconciliation step.

Migration sequence from inventory to decommission

This sequence moves Workato recipes into Apache Camel routes one flow at a time, proving each route against the behavior of the recipe it replaces before traffic moves. Each step ends with a named artifact so the team can see what is finished and what is still running on Workato.

Build the recipe inventory from exported packages
Export the recipe packages from Workato using the lifecycle management manifest, then list every recipe, its trigger, its connectors, its lookup table dependencies and its owner. Integration developers do this work, with the business owner of each flow confirming its purpose. Classify each recipe by connector family and by complexity, such as branching, error handling, retries and data transformation, so that simple flows and heavy flows are planned differently. The step closes with a route catalog: one row per recipe, with its target component set, its owner and the questions that still need an answer. Confirm the export includes everything you need in your own Workato edition, because packaging and dependency coverage should be checked against the export documentation before you rely on it.
Map connectors to Camel components
For each connector in the catalog, identify the Apache Camel component that covers the same system, or record that no component exists and a custom bean or client will be needed. Check version and authentication requirements, including how secrets will be held outside Workato. Kafka, REST, JDBC and the cloud components are common starting points, but each mapping should be verified against the component documentation in the Camel repository. The output is a connector mapping table with a status per row (covered, partial or custom build), which becomes the input for effort estimation with your implementation partner.
Stand up a pilot route on Spring Boot or Quarkus
Choose one low-risk recipe that uses common connectors and build it as a Camel route in Java, YAML or XML on Spring Boot or Quarkus. Choose the runtime based on your existing platform standards and whether you need native compilation. Set up the build pipeline, configuration handling, logging and health endpoints the same way the rest of your services run. The pilot proves the toolchain and the team's operating model. It is done when the route builds and deploys in a non-production environment and the team can explain every design decision in it. Kaoto can help developers visualize the route, but the source of truth should remain the code in version control.
Run parallel testing and reconcile outputs
Feed the same inputs to the Workato recipe and the Camel route, either by replaying captured events or by running both against a staging copy of the source systems. Compare outputs field by field, including error paths, retries, timing-sensitive behavior and side effects such as records written to target systems. Record each difference, classify it as an intended change or a defect, and fix the route until the unintended differences are gone. The output is a test evidence pack containing the test cases, the input data (with personal data masked or minimized), the reconciliation results and sign-off from the business owner. Keep the evidence for your change records, since it is what reviewers and auditors will ask to see.
Cut over flows one at a time
Move recipes to Camel in batches, starting with the lowest-risk flows and ending with the flows that touch critical data. For each flow, write a cutover runbook covering the switch of triggers, the pause of the Workato recipe, the rollback steps, the monitoring to watch after the switch and the named people who make the call. Confirm that duplicate processing cannot occur during the window when both systems could be active. Each flow is considered cut over when the Camel route is the only active processor, the rollback path has been rehearsed, and the runbook is signed off. Keep the Workato recipe paused rather than deleted until the post-cutover review is complete.
Operate the routes and monitor them
Once routes carry production traffic, operate them with the same standards as other production services. Set up logging, metrics, alerting, dead-letter handling and version-controlled deployment through your existing pipeline. Confirm who owns each route, how incidents are triaged and how Camel upgrades are tested, paying attention to the release lines and end-of-life dates published by the Apache Camel project. The output is an operations handbook and a monitoring baseline for each route. This step runs until the last flow is moved and the post-cutover reviews have closed.
Decommission Workato recipes and the on-prem agent
After every flow has run on Camel through its agreed review period, retire the paused Workato recipes and confirm that nothing else depends on them. Remove the on-prem agent from each network segment and revoke its credentials, then confirm that the outbound WebSocket tunnel no longer exists in your firewall and proxy logs. Review your Workato contract with your procurement team to confirm the end date and any data return or deletion obligations. Keep the final exports, the route catalog and the test evidence as an archive. The decommission is complete when the agent is removed, credentials are revoked, the contract end is confirmed in writing and the archive is filed.

What drives cost and duration in a Camel rebuild

This table lists the factors that move the effort of rebuilding Workato recipes as Camel routes, why each one matters, and how to keep it under control. Read the first column as the driver and the other columns as the reason and the lever. The main takeaway is that the recipe inventory and the share of custom code matter more than the platform fee, which is small by comparison.

Driver	Why it moves cost or effort	How to keep it down
Recipe count and complexity	Each recipe needs mapping, error handling, retries and testing. Branching, loops and nested sub-recipes multiply the work per recipe.	Triage the lifecycle management export first. Retire unused recipes and group near-identical ones into shared routes.
Number and type of connectors	Each Workato connector must be matched to a Camel component, and some SaaS connectors may need a custom component or direct HTTP calls.	Map connectors in a table before coding. Confirm component coverage for each one against the Camel component catalog.
Custom code in recipes	Ruby or formula-based logic and embedded scripts must be rewritten in Java, YAML or XML, and their behavior must be verified again.	Count custom code blocks in the export. Move shared logic into tested Java beans once, not per route.
On-prem and private system access	Routes running inside your network need network paths, credentials stored in your secrets tooling and firewall changes. The Workato on-prem agent does not carry over.	Document each private endpoint early. Deploy routes in the same network segment as those systems and reuse existing connection patterns.
Java skill on staff	Teams without Java experience need training or hiring, which adds internal developer time before the first route ships.	Assess skills before scoping. Pair experienced Java engineers with Workato builders, or ask a partner to help with the first routes.
Testing and observability requirements	Recipes often have no automated tests. Camel routes need unit, integration and message-level tests, plus metrics, logs and tracing to replace Workato run history.	Agree on test coverage and telemetry standards before the rebuild. Reuse the same test cases to compare Workato and Camel outputs.
CI/CD setup	Without a pipeline, route deployments are manual and slow to repeat across environments. Building the pipeline is a one-time cost that pays back with each release.	Store routes in Git and build one pipeline template for Spring Boot, Quarkus or Kubernetes targets. Reuse it across all routes.
Runtime and Kubernetes operations	Hosting, patching, scaling and on-call support recur for every runtime you run, and they grow with the number of routes and environments.	Consolidate routes into fewer deployable units where it makes sense. Confirm who owns patching and on-call before go-live.
Optional Red Hat subscription	Red Hat's commercial support for the Red Hat build of Apache Camel is a recurring subscription if you choose it. Apache Camel itself is Apache-2.0 licensed with no license fee.	Decide on support needs early. Ask Red Hat for current subscription terms and confirm which runtimes and versions are covered.

What usually goes wrong and how to prevent it

Most failed Workato to Apache Camel migrations do not fail on the first route. They fail on behavior that changed quietly, on credentials and lookups that were rebuilt by hand, or on a runtime that was chosen without checking its support window. Each card below names one of these risks and the check that prevents it.

Silent differences in error handling

Workato recipes handle errors, retries and skipped steps through their own error and retry settings, and Camel uses its own error handler, redelivery policy and exchange model. A route can look correct in a test and still retry, dead-letter or drop messages differently under load. Write down how each Workato recipe behaves on failure, then set Camel's error handler and redelivery values explicitly and test a forced failure for every route.

Unmapped connector fields

Workato connector actions expose fields that do not always have a one-to-one match in a Camel component. Optional fields, pagination settings, date formats and object identifiers are common gaps, and they often fail only with real data. Build a field map for each connector from the exported JSON, mark every field as mapped, transformed or dropped, and sign off each dropped field with the business owner of the recipe.

Credentials recreated incorrectly

Exported recipe packages describe connections but do not carry usable secrets, so every connection must be created again in Camel's configuration or in your secrets store. Mistakes include using a shared service account where the recipe used a per-user OAuth grant, or copying a token into a properties file. Inventory each connection, record its auth type and scopes, and store secrets in your vault with separate credentials per environment.

Lookup table drift

Workato lookup tables act as reference data inside recipes, and they are often updated by business users without a code change. When those values are copied once into a Camel properties file or a database table, they begin to drift from the source. Decide who owns each lookup after migration, move the data into a versioned store, and add a comparison job that flags differences between the old and new values during parallel running.

Skipping parallel runs

Cutting over every recipe at once removes the chance to compare outputs, and duplicate or missed records are hard to trace after the old system is switched off. Run the Camel route alongside the recipe against a copy of the traffic or a sandbox, compare outputs record by record, and keep the Workato recipe available for rollback until the comparison is clean. Set the length of that window in writing before you start.

Runtime version chosen against LTS dates

Camel publishes standard and LTS releases with different support windows, and LTS releases receive fixes for a longer period. Choosing a version without checking its end-of-life date can leave production routes unpatched within the first year of operation. Pick an LTS line that matches the Java version your platform team supports, record its end-of-life date in the operations calendar, and plan the upgrade before that date arrives.

Underestimating Java operations skills

Workato hides the runtime, scaling and patching from the integration team, and Camel does not. Someone must own JVM tuning, container images, Spring Boot or Quarkus upgrades, dependency vulnerabilities and on-call debugging of routes. Name the owner for each runtime before the first route goes live, and confirm that the team has written runbooks for deploys, rollbacks and log triage.

How the migration differs by starting point

A small estate with one developer is usually a question of sequencing and discipline rather than platform design. The exported package gives you a complete inventory of recipes and dependencies, so the first step is to read it and decide which recipes are worth rebuilding as routes at all. Many simple recipes are one trigger, one transformation and one action, and a single Camel route in YAML or Java can carry them with little ceremony.

Inventory first: List every recipe in the export, mark the ones that are dead, duplicated or unused, and retire them before writing any code.
One route per recipe: Start with a single route for a low-risk recipe so the developer learns the component mapping before tackling anything complex.
Pick one runtime: Choose Spring Boot or Quarkus once for the whole set so the build and deployment pattern stays consistent.
Use Kaoto for review: The Kaoto visual designer can help a single developer check route structure against the original recipe diagram.
Document the connection rebuild: Record each connection's credentials and owners, because they must be recreated in your secrets store.

Before you commit, confirm with a second engineer that someone else can operate the routes after the developer moves on.

Questions integration teams ask before moving from Workato to Camel

How much does a move from Workato to Apache Camel cost?

Apache Camel itself is free to download and use under Apache-2.0, so the cost is the work around it. Those costs are the engineering effort to rebuild recipes as routes, the runtime and infrastructure you operate on Spring Boot, Quarkus or Kubernetes, testing and monitoring, and ongoing maintenance. Workato's own fees are a separate line you stop paying once workloads are retired. No supplied figure gives a total, so ask any implementer for a quote built from a written scope, and ask for the recipe count, connector count and environments that drive it. Compare one-time rebuild effort against recurring platform operations and support.

How long does it take to rebuild Workato recipes in Camel?

The duration depends mostly on how many recipes you have, how many use custom logic or unusual connectors, and how many environments must be validated. Start by inventorying recipes from the lifecycle management export, then group them by complexity. Simple recipes that map to standard Camel components are quick to rebuild, while recipes that depend on on-prem connections or lookup tables take longer. No supplied timeline exists for this work, so ask your team or any partner to propose a phased plan with milestones, and confirm it in writing before work starts.

What skills does our team need to run Camel routes?

Your team needs Java developers comfortable with Camel routes written in Java, YAML or XML, plus operations skills for the runtime you choose. The runtime might be Spring Boot with connector starters, Quarkus, the Camel CLI, or Camel K on Kubernetes. Your engineers also need to handle build pipelines, configuration, secrets, logging and metrics, and upgrades. Workato's low-code users will need training in code review and testing. If you lack these skills in-house, a fixed-scope engagement can cover the rebuild, but you should still plan for staff who own the routes afterward.

Can our own team do the migration without outside help?

Yes, if your team has enough Java integration experience and time to rebuild and test recipes alongside its regular work. The Workato package gives you the recipe logic to work from, and Camel's documentation and Kaoto can help with design. The risks are underestimating recipe complexity, missing edge cases in error handling, and running a parallel period without clear cutover criteria. Many organizations bring in an outside team for the first wave of routes and the production hardening, then transfer ownership. Whichever route you choose, agree on scope and acceptance tests before starting.

Should we pick the Camel LTS release or the standard release?

Choose an LTS release for production routes that you expect to run for a long time without frequent upgrades. Camel's download page lists Apache Camel 4.22.1 as LTS with end of life in August 2027, and Camel 4.18.5 LTS with end of life in February 2027. The page also lists Camel 4.23.0 as the latest standard, non-LTS release in October 2026. LTS releases receive bug and security fixes for up to one year. Standard releases suit teams that upgrade frequently. Confirm the current end-of-life dates on the download page before you commit, and plan your upgrade path before the chosen line ends support.

What does Kaoto do in a Camel migration?

Kaoto is an Apache-2.0 licensed visual designer for Apache Camel integrations. It is available as a VS Code extension from the Microsoft Marketplace or Open VSX, and it is developed under the KaotoIO GitHub organization with support from Red Hat. It helps engineers who come from low-code tools see and edit route structure visually while the output remains Camel code. It does not replace code review, testing or runtime operations. Check that the Kaoto version you install supports the Camel release you have chosen before you standardize on it.

What does Red Hat support cover for Apache Camel?

Red Hat sells commercial support for its build of Apache Camel through Red Hat Application Foundations or Red Hat Integration subscriptions. According to Red Hat Developer, that support covers Spring Boot and Quarkus runtimes, and it no longer covers OSGi (Karaf) or JBoss EAP. Apache Camel remains free to use without that subscription. Ask Red Hat or your reseller which products and versions your subscription includes, and whether it covers the runtimes you plan to use. Support is an option you can add, not a requirement for running Camel.

How does Camel licensing differ from n8n or Windmill?

Apache Camel is licensed under Apache-2.0 and maintained by the Apache Software Foundation, which makes it the most permissive option among these three. n8n's main codebase is under the Sustainable Use License, which allows internal business use but requires a valid Enterprise License for files with .ee in their name. Windmill's source compiled without the enterprise feature flag is under AGPLv3 and Apache-2.0, while its prebuilt Community images include proprietary code that is free for internal use but needs a commercial license for managed services or resale. Have legal counsel review the license text for your exact use before you decide.

How DeployOpen scopes and runs a Workato to Camel migration

DeployOpen treats each Workato to Apache Camel migration as a fixed-scope engagement, with scope, deliverables and timelines agreed in writing before work starts. The work runs inside your own infrastructure, from the exported recipe packages through to routes you operate and maintain.

How we scope

Inventory every recipe, dependency and lookup table in the exported package before estimating any rebuild work
Map each Workato connector to a Camel component, and flag connectors that need custom code or a vendor SDK
Agree the target runtime in writing, whether Spring Boot, Quarkus or Kubernetes, along with the Java version and deployment model
Confirm which on-prem systems, networks and credentials the routes must reach, and who approves access

How we build

Rebuild recipes as Camel routes in Java, YAML or XML, keeping the Workato package as the functional specification
Recreate connections and secrets in your own secret store so credentials never sit in route files or source control
Test each route against the behavior recorded in the original recipe, including error handling, retries and data mappings
Set up the Kaoto visual designer where your team wants a visual view of routes alongside the code

How we hand over

Deliver a route inventory that maps each original Workato recipe to its Camel route, with open items listed
Document build, deployment, configuration and rollback steps so your engineers can run the routes without us
Run knowledge transfer sessions with your developers and operations staff, covering monitoring and incident handling
Agree on a parallel-run and cutover plan in writing, with a clear record of which recipes were switched off

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover, scoped in writing
Plan upgrades against the Camel release and end-of-life dates your team has chosen to follow
Confirm with your team whether Red Hat commercial support for the Camel build is part of the target stack
Ask for a quote based on the written scope, which DeployOpen provides without a published price list

Migrate from Workato to Apache Camel