Migrate from Azure Logic Apps to Apache Camel

Migrate from Azure Logic Apps to Apache Camel: what the move involves

The move from Azure Logic Apps to Apache Camel is a rebuild of each integration as code, not a file conversion. A Logic Apps workflow definition describes triggers, actions and connector calls in a designer-oriented JSON format, and a Camel route is a Java, YAML or XML program that you write, test and deploy yourself. Teams usually start this work because they run message-heavy or B2B integrations, because a renewal or hosting constraint forces a decision, or because they want those integrations running on their own Kubernetes. In every case, plan for the rebuild to be done by people, route by route. Integration engineers with Java or YAML skills do most of the build, since they map each trigger, transform and connector into Camel components and write the error handling. Platform engineers own the runtime: the Camel deployment on Spring Boot, Quarkus or Camel K, the message broker, secrets, logging and scaling. Security staff should review credentials, network paths to each endpoint and how TLS and authentication are configured for each component. Effort is driven by the number of integrations, the amount of custom XML or flat-file transformation, and how many managed connectors have no direct equivalent that your team can verify.

Treat the Logic Apps export as an inventory, not as a runnable Camel definition. The exported JSON and ARM templates tell you what each workflow does, which connections it uses and which schemas and maps it depends on, but they do not generate Camel routes, and integration account artifacts such as XML schemas and maps must be re-created and tested in the new stack. Use the export to record each workflow's trigger, retry behavior, message volume and downstream systems, then decide per workflow whether it becomes a route, a broker-backed flow or a job. Before cutover, run old and new routes side by side on representative messages, check duplicate handling and dead-letter behavior, and confirm with your Camel and broker vendors or support contacts which versions and lifecycle dates apply to your environment.

Which Logic Apps capabilities map cleanly to Camel and which need rework

This table compares common Logic Apps capabilities with their Apache Camel equivalents and marks each as clean, needs rework or gap. Managed connectors need a per-connector check against Camel components before you commit to a migration plan. Use the table to size the rebuild work, not to predict effort exactly.

Logic Apps capability	Apache Camel equivalent	Status
Triggers and actions in workflow JSON	Routes built from endpoints, EIPs and processors, written in Java, YAML or XML	Needs rework: definitions are rebuilt by hand, not converted automatically
Managed connectors (Office 365, Salesforce, SQL, Blob Storage and similar)	Camel components such as Salesforce, JDBC, Azure and REST, where a match exists	Needs rework: confirm a component equivalent for each connector; some may be gaps
XML transforms and XSLT maps	XSLT and XML data formats, with XPath and Java processors	Clean: usually a direct translation, but re-test namespaces and edge cases
Flat-file parsing (EDI and delimited files)	Camel data formats for CSV, fixed-length and EDI, or custom processors	Needs rework: field definitions and delimiters must be re-specified and tested
Integration account schemas and maps	XSD and XSLT assets kept in version control and loaded by routes	Needs rework: artifacts must be exported and re-validated outside Azure
Service Bus queues and topics	Kafka topics or RabbitMQ queues, chosen per workload and delivery requirement	Needs rework: broker choice, ordering, sessions and dead-letter behavior must be redesigned
Retry policies and run-after error handling	Camel error handler, redelivery policy and dead letter channel	Needs rework: retry counts and backoff must be set again explicitly
B2B agreements, trading partners and AS2 or EDI support	Camel AS2 and EDI components, or custom partner logic	Gap: confirm component coverage and certification needs before scoping

What to export and what to rebuild from the Logic Apps estate

Before any route is written, the Logic Apps estate needs an inventory built from what can be exported and what must be rebuilt by hand. The cards below separate the artifacts that carry over as reference material from the pieces that must be re-established in Camel, your broker, and your secrets store.

Workflow definitions as the baseline

The JSON workflow definition describes triggers, actions, run-after conditions and parameters for each Logic App. Treat it as the primary inventory record: list every workflow, its trigger type, every connector action and every nested scope. Check which workflows call child workflows or depend on Service Bus sessions, because those dependencies decide the order of migration. The definition explains intent, but it does not run in Camel, so each action still needs a route design.

ARM templates for deployment context

ARM templates capture how each Logic App, its hosting plan and its supporting resources were deployed, including app settings, parameters and linked resources. Use them to record environment-specific values such as endpoints, queue names and retry settings that the workflow definition alone does not show. Expect parameters to hold references to Key Vault secrets, which must be mapped to your own secrets store rather than copied.

Connection objects and their secrets

API connection resources store how each managed connector authenticates to a backend. The connection definitions can be listed and documented, but credentials, managed identity bindings and OAuth tokens do not carry over. Each connection must be re-established in your environment with a service account, a client certificate or a secret held in a vault you operate. Record the owner, scope and rotation method of every connection before cutover.

Schemas and maps as Camel data formats

Integration account artifacts such as XML schemas, flat-file schemas and XSLT maps have no direct import path into Camel. Schemas map to Camel data formats for XML, JSON or CSV parsing and validation, and maps become XSLT steps or transform processors. Compare sample messages against the original map output on real traffic copies, since mapping functions often behave differently across engines.

Connector calls as Camel components

Each managed connector action needs a matching Camel component or a custom endpoint. Database, REST, file, AWS, Azure, GCP and Salesforce calls have established components, and the Camel repository lists more than 350 connectors. Where a connector has no component, plan a custom processor and record the gap as a project risk. Confirm each component version against the Camel release you select.

Where a broker replaces Service Bus

Service Bus queues and topics usually become RabbitMQ for AMQP 1.0 and MQTT or STOMP clients, or Kafka for high-throughput, replayable event streams. RabbitMQ quorum queues use Raft replication and replace classic mirrored queues. Kafka supports SASL mechanisms including SCRAM-SHA-512 and OAUTHBEARER and TLS encryption, but security is optional, so enforce it on every listener. Choose the broker per flow, not for the whole estate.

Migration sequence from inventory to decommission

This sequence moves Logic Apps integrations to Apache Camel routes one at a time, so each route is proven against live traffic before the Logic Apps original is switched off. Each step produces a record the next step depends on, and nothing is decommissioned until its replacement has a documented cutover.

Build the inventory and classify each integration
Export every Logic Apps workflow definition, ARM template and connection reference, then list the triggers, actions, managed connectors, integration account artifacts such as schemas and maps, and the systems each workflow calls. Classify each integration by business criticality, message volume, whether it is request-response or asynchronous, and whether it depends on Service Bus, a file share or a B2B partner. Your platform or integration lead owns the register, and it is complete when every workflow has an owner, a classification and a named replacement pattern. Ask your implementation partner to confirm the register matches what runs in production, since exports do not always show run history or connections in use.
Confirm consumer idempotence before any parallel run
Before running Camel routes alongside Logic Apps, document for each downstream consumer whether it can safely receive the same message twice and how it detects duplicates, using message IDs, business keys or database constraints. Also record which Logic Apps retry settings and Service Bus duplicate detection windows are in effect, so you know where duplicates may already arise. The integration owner and each consuming system owner sign this off. The output is a duplicate-handling register. Parallel running does not start for any flow whose consumers have not confirmed this in writing.
Translate and prove a pilot route in a non-production environment
Choose one non-critical integration with a clear input and output, then rebuild it as a Camel route in Java, YAML or XML, mapping connector calls to Camel components and rewriting XML or flat-file transforms with the same schemas. Use Kaoto if your team wants a visual view of the route alongside the code. Run the route against recorded or synthetic messages and compare outputs field by field with the Logic Apps run history. The output is test evidence: input samples, expected and actual results, and a list of accepted differences. The pilot is complete when a named reviewer accepts that evidence.
Write the runbook for deployment and operations
Document how the route is deployed, whether on Spring Boot, Quarkus, the Camel CLI or Camel K on your Kubernetes, and how it is monitored, restarted and rolled back. Cover broker configuration if messages move from Service Bus to a broker such as RabbitMQ or Kafka, including queue types, dead-letter handling, retry policy and access controls. The operations team signs the runbook. It is complete when an engineer who did not build the route can deploy, verify and roll it back from the document alone.
Run in parallel with duplicate controls
Route a limited share of messages to the Camel route while the Logic Apps workflow continues, using the duplicate-handling register to decide which consumers receive output from each side. Compare results continuously and log every mismatch with its cause. Keep the parallel period open until the mismatch log shows no unexplained differences across the traffic patterns you classified, such as month-end batches or partner retries. The output is a parallel-run log that the business owner reviews before any cutover decision.
Cut over route by route and record each switch
Move production traffic to the Camel route for one integration at a time, keeping the Logic Apps workflow disabled but restorable as the rollback path. Record the change window, the approver, the verification checks run after switching and the rollback trigger used. Do not batch several integrations into one cutover, so a fault can be traced to one route. The cutover record for each route is the evidence the change board needs, and the next route starts only after the previous one has run cleanly on its own.
Decommission Logic Apps resources with a checklist
After each route has run in production without a rollback for the period your operations team defines, remove the Logic Apps workflows, API connections, integration account artifacts and any Service Bus entities that no route uses. Check first that no other system, alert or report still reads from them, and keep exported definitions and run history in your archive for audit. The decommission checklist, signed by the integration owner and the security team, records each resource removed, its replacement and where its archive copy is stored. Ask your Azure administrator to confirm billing has stopped for each resource.

How Camel routes, Kubernetes and brokers fit together after the move

A Camel route is the unit you deploy, and it runs in one of four shapes: through Camel K on Kubernetes, as a Spring Boot application, as a Quarkus application, or standalone from the Camel CLI. For most Logic Apps teams moving onto their own cluster, Camel K is the closest fit because it is built from Apache Camel for Kubernetes and is designed for serverless and microservice patterns, so each integration becomes a deployable unit with its own scaling and rollout. A Spring Boot or Quarkus build suits teams that already run those runtimes and want routes packaged with the rest of their services. In every shape, the route consumes from a source endpoint and produces to a target endpoint, and the broker sits between them when the Service Bus queue or topic pattern needs to be preserved. Decide the runtime before you translate workflows, because it determines how connection settings, secrets and health checks are wired. The trust boundary falls at three places. Inside the cluster, the Camel pods and the broker should sit in a namespace that only the integration team can administer, with credentials for the broker and downstream systems held in Kubernetes secrets rather than route files. Between the cluster and the broker, the broker's own authentication and authorization decide which routes may publish or consume each queue, and for Kafka the authorization documentation notes that resources without ACLs are restricted to super users unless allow.everyone.if.no.acl.found is set, so confirm that setting before go-live. Between the cluster and external systems, such as partner APIs or SaaS endpoints, the egress path is the control that matters, and it should be allowed only to the destinations each route documents. Ask your security team to review these three boundaries as a single diagram before cutover. Version choice and vendor support should follow the same discipline. The Camel download page lists 4.22.1 and 4.18.5 as LTS lines with end-of-life dates in August 2027 and February 2027, so favor one of these for production and confirm the dates against the current page before you commit. Red Hat's commercial support for the Red Hat build of Apache Camel covers Spring Boot and Quarkus runtimes only and no longer covers OSGi (Karaf) or JBoss EAP, so if your organization needs vendor-backed support, a Camel K or Spring Boot design fits that boundary. Confirm the support scope in writing with your procurement team before you choose the runtime.

How the migration changes by team size and starting point

A small team with a handful of stateless workflows, such as HTTP-triggered transforms, scheduled database calls or notifications, usually has the simplest migration. Each workflow can be read end to end, rebuilt as a Camel route in Java, YAML or XML, and tested on its own. The scope is narrow, so the work is mostly rebuilding connector calls with the right Camel components and wiring retries and error handling into each route.

Scope: Inventory the exported Logic Apps definitions and mark which ones are stateless. Move those first and leave stateful or long-running flows for later.
Skills: One or two developers who know Java or YAML and are comfortable with Camel's route DSL are usually enough. The team needs a plan for who will operate the runtime after cutover.
Broker: Most small estates can call the target system directly, so a message broker may not be needed at first. Confirm this against the actual Service Bus usage in the inventory.
Parallel run: Run old and new routes side by side on the same test messages. The length of this period depends on how often each workflow runs, which the team should measure from its own run history.
Operations: Ask whether the team will host Camel on Kubernetes, on Spring Boot or as a standalone process, since that choice shapes monitoring and deployment.

Before committing, check that the inventory really is stateless, because a single hidden dependency on a managed connector can change the plan.

What usually goes wrong and how to prevent it

Most failed Logic Apps to Camel migrations break at the seams: messages processed twice, brokers that deny access by default, version mismatches and connectors that behave differently from their managed counterparts. Each card below names one of these failure points and the check that catches it before cutover.

Duplicate processing during parallel runs

While Logic Apps and Camel routes both consume the same source, a message can be handled twice, for example an order submitted twice or a payment posted twice. Logic Apps trigger deduplication and retry state do not carry over automatically. Run each route in shadow mode with a single consumer group or queue, and compare outputs per message ID before switching producers. Confirm that every downstream system rejects or ignores repeated keys.

Lost ACLs on new brokers

Permissions configured on Service Bus queues or topics do not move to a new broker. In Kafka's KRaft mode, the StandardAuthorizer restricts resources that have no ACL to super users unless allow.everyone.if.no.acl.found is set to true, so producers and consumers can fail with authorization errors at cutover. Create an explicit ACL for every topic and consumer group before deployment, and document each one from the Logic Apps connection inventory. Test denied access as well as allowed access.

Unsupported broker or Java versions

Upgrading a broker or runtime can break a route that worked on the previous release. Kafka 4.0 supports only KRaft mode, so ZooKeeper-based clusters must migrate first, and brokers, Kafka Connect and tools require Java 17. Camel release lines also have different end-of-life dates. Pin the Camel LTS line and the Java version in the build, and check the broker upgrade path against the Kafka upgrade notes before scheduling any upgrade.

Connector behavior differs from managed connectors

Logic Apps managed connectors handle authentication, paging, throttling and schema handling in ways that a Camel component may not. A JDBC or REST call that returns a different page size, date format or error code can silently change downstream data. Build a contract test for each connector that compares the Logic Apps response with the Camel response on the same input, and record every field mapping that changed. Confirm each component's options with its documentation rather than assuming parity.

Missing error handling and retry parity

Logic Apps retry policies, run history and run-after settings define how failed actions recover. Camel routes need explicit error handlers, redelivery policies and dead-letter destinations, and none of these are added automatically. Map every Logic Apps retry and run-after setting to a named Camel error handler, and test each failure path with a forced fault so the team knows where failed messages land and who reprocesses them.

What drives migration cost and duration, and how to control each

This table lists the main factors that raise or lower the cost of rebuilding Logic Apps workflows as Apache Camel routes. Read each row as a lever: the driver, why it moves effort, and the step that keeps it under control.

Driver	Why it moves cost or effort	How to keep it down
Number and complexity of integrations	Each workflow needs its own route design, error handling, retries and tests. Branching, loops, nested scopes and long-running waits add the most design time per workflow.	Export the Logic Apps inventory first, then group workflows by shared pattern (for example, file ingest, REST enrichment, queue fan-out) so one route template covers many flows.
Transform and schema volume	XML mapping, XSLT, flat-file parsing and JSON-to-XML conversions must be re-implemented with Camel data formats and transforms. Integration account schemas and maps add a second source of truth to reconcile.	Count schemas and maps in the export, retire unused ones, and move shared transforms into tested reusable components before rebuilding the flows that call them.
Connectors without a direct Camel equivalent	Managed connectors have no one-to-one match in Camel. Each gap needs a Camel component, a custom processor, or a direct call to the vendor API, and each option carries its own authentication and error model.	List every connector in use, map it to a Camel component from the component catalog, and flag gaps early. Replace rarely used connectors with plain HTTP calls where the vendor API is stable.
Broker choice and operations	Replacing Service Bus with RabbitMQ or Kafka changes queue semantics, dead-letter handling, ordering and retention. Running a broker cluster adds operating work that Azure currently carries for you.	Decide per flow whether a queue, a stream or a direct HTTP call fits, then size one broker tier for the workloads that need it. Confirm supported versions and lifecycle dates with each vendor before committing.
Idempotence and delivery guarantees	Logic Apps retry policies and run history do not carry over automatically. Duplicate messages during cutover or retries can corrupt downstream data and cause expensive reconciliation.	Define idempotency keys and dead-letter routes per integration during design, and test duplicate delivery explicitly rather than assuming the broker prevents it.
Testing depth	Route-by-route testing with recorded inputs, transform fixtures and failure injection takes more time than a visual review. Skipping it moves cost into production incidents.	Write fixture-based tests for each transform and route, run parallel traffic against the Logic Apps flow during cutover, and agree acceptance criteria in the written scope.
Team Java skill	Camel routes are code-first in Java, YAML or XML, so teams without Java experience need training or hiring before the work can move. Skill gaps lengthen review cycles and raise dependence on a few engineers.	Assess skills before scoping, use YAML or XML DSL for simpler routes, and use Kaoto as a visual designer for teams new to Camel. Ask any implementation partner to name who will maintain the routes after handover.
Deployment target and runtime choice	Choosing Spring Boot, Quarkus, the Camel CLI or Camel K on Kubernetes changes build pipelines, container images, and operator skills. Mixing runtimes across teams multiplies support work.	Standardize on one runtime and deployment pattern for the first wave, then reuse the pipeline for later waves. Confirm the Camel release and Java version against the current download page before starting.

Questions buyers ask before moving from Logic Apps to Camel

How much does moving from Logic Apps to Apache Camel cost?

The cost is driven by scope, not by the Camel license, because Apache Camel is Apache-2.0 licensed and carries no license fee. The main components are the build effort to rebuild each workflow as a route, the infrastructure to run Camel (typically containers on Kubernetes or standalone services), a message broker if you need one, testing, and ongoing operations. Recurring costs are infrastructure, support and upgrades. Ask any quote to break these out per component, and to state which workflows, connectors and transforms are in scope. Figures should come from a written scope, not a generic estimate.

How long does a Logic Apps to Camel migration take?

Duration depends on the number of workflows, how many use XML or flat-file transforms, how many depend on managed connectors with no direct Camel component, and how much message traffic must be carried over. Long-running or B2B workflows with stateful correlation usually take longer to design and test than simple event handlers. Your team's familiarity with Java, YAML or XML routes also matters. Ask for a timeline tied to a workflow inventory and milestones, and confirm which environments and test data the plan assumes.

What does the migration need from our own team?

You need owners for the business rules behind each workflow, engineers who can build and review Camel routes, someone who runs the target platform (Kubernetes, the broker, monitoring and backups), and a security contact for credentials and network access. Camel is code-first, so teams that only know a visual designer need training or pairing. Logic Apps' managed connectors are replaced by component configuration, so connection secrets and identity setup must be owned by your team from the start.

Can we do this migration in-house?

Yes, if the team has Java or Camel experience, time for a pilot, and capacity to run the platform after go-live. Many teams start with one low-risk workflow to learn the patterns, then decide which remaining workflows to take on. Teams with little integration experience, many compliance-bound workflows or a tight deadline often bring in outside help for the design and testing phases. DeployOpen plans, implements, hardens, documents and supports self-hosted platforms in your environment under a fixed scope agreed in writing before work starts, and ongoing support is available as a retainer.

Does Apache Camel have a connector for every Logic Apps connector?

No, and you should not assume it does. Apache Camel lists more than 350 connectors, including Kafka, REST, JDBC, AWS, Azure, GCP and Salesforce, but the match to each Logic Apps managed connector must be checked one by one. Some connectors may map to a Camel component with different configuration or authentication, some may need a custom component or a call to a REST API, and some SaaS connectors may have no direct equivalent. Build a connector matrix during inventory and mark each row as direct, indirect or custom.

Do we need a message broker to replace Azure Service Bus?

Only where a workflow needs queuing, decoupling or delivery guarantees that a direct HTTP or JDBC call cannot provide. Options include RabbitMQ, which supports AMQP 1.0 as a core protocol and uses quorum queues based on the Raft consensus algorithm, and Apache Kafka for high-volume event streams. RabbitMQ and Kafka both have different operational models and lifecycle schedules, so compare them against your message patterns, retention needs and team skills. Confirm delivery semantics, ordering and dead-letter handling for each flow before choosing.

How do we cut over without downtime?

Move workflows one at a time, running the Camel route alongside the Logic Apps workflow where the source system allows it. Start with read-only or idempotent flows, compare outputs in a parallel run, then switch traffic or triggers workflow by workflow. Make sure consumers handle duplicate messages during the overlap, and keep the Logic Apps definition and its connections available until rollback is no longer needed. Written cutover plans should name each workflow, its rollback step and the owner who approves the switch.

Which skills and checks should we confirm before we start?

Confirm the Java version and Camel release line you will run. Apache Camel 4.22.1 is an LTS release supporting Java 17, 21 and 25, and LTS releases receive bug and security fixes for up to one year. Check that Kubernetes, the broker and logging stack are supported by your operations team. Verify how credentials will be stored, how routes will be tested and version-controlled, and how Kaoto or other designers fit your workflow. Ask your vendor or integrator to confirm each item against your own environment.

Primary sources to check during planning

Start with the Apache Camel repository and download page before you choose a runtime or a release line. The download page lists which releases are LTS, which Java versions each supports and the end-of-life dates for each line, and it lists the subproject releases (Camel Quarkus, Camel K and Kamelets) that you will pin alongside the core. Pick the runtime that matches your team's skills, whether Spring Boot, Quarkus or standalone, and check the component list in the repository against every Logic Apps connector your inventory shows you rely on. Where a connector has no matching Camel component, record it as a gap to rebuild or replace, and confirm the version you plan to deploy has the component you need.

Next, read the Camel K documentation if your target is Kubernetes, and open Kaoto to see whether its visual designer covers the route patterns your team will use before you decide how much of the work will be code. Kaoto is an Apache-2.0 designer, so confirm which features it supports in the version you install. For the messaging layer, check the RabbitMQ release information and the RabbitMQ quorum queue documentation together: confirm which release line is still in community support on the planned cutover date, which commercial support options exist if you need a longer lifecycle, and that your broker design uses quorum queues rather than the classic queue mirroring that RabbitMQ 4.0 removed. If you are weighing Kafka instead of RabbitMQ, read the Kafka upgrade notes and the security overview, paying attention to the KRaft requirements, the supported Java runtime and the SASL and authorization defaults. Confirm each version number and lifecycle date directly in its source before you commit, because these pages change with every release.

How DeployOpen scopes, runs and supports a Camel migration

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For a move from Azure Logic Apps to Apache Camel, we start with a written scope that names the workflows, connectors and message paths in play, then rebuild them as Camel routes and test each route before cutover.

How we scope

Written scope lists the Logic Apps workflows, connectors, integration account artifacts and message volumes to be rebuilt as Camel routes
Scope states which Service Bus queues and topics move to RabbitMQ or Kafka, and which stay in Azure during transition
Engagements are fixed-scope, with deliverables and timelines agreed in writing before any route work begins

How we build

Routes are written in Java, YAML or XML on the runtime your team chooses, such as Spring Boot, Quarkus or Camel K on Kubernetes
XML and flat-file transforms are rebuilt as Camel data formats and tested against sample messages from your own estate
Connector calls are mapped to Camel components, with credentials held in your own secrets store rather than in route code

How we hand over

Each route ships with a test suite, a runbook, a deployment definition and a record of differences from the original Logic Apps behavior
Handover includes a route-by-route inventory showing which workflows are migrated, parallel-run or retired
Your team receives documentation for operating brokers, routes and upgrades in your own environment

How we support

Ongoing support, upgrades and continuous testing for Camel routes are available as a retainer after handover
Upgrade planning covers Camel LTS and standard release lines, so your team knows which versions receive longer fix windows
Support scope, response expectations and fees are set in the written agreement, and we will confirm them in your quote

Migrate from Azure Logic Apps to Apache Camel