Why Mule 4.6 end of support forces a MuleSoft alternative decision
The decision is whether to upgrade your Mule 4.6 estate to Mule 4.9 LTS or move those integrations to a self-hosted alternative. For this page, that alternative is Apache Camel, an Apache-2.0 integration framework. Mule 4.6 LTS leaves Standard Support in August 2026, and Java 8 support ends with it, so the first step is to record which runtimes, Java versions and deployment targets each application uses today. The right answer depends on how much of the estate is custom code, because a team with mostly standard connectors faces a very different workload than a team with many bespoke ones.
Custom connectors are the constraint that applies to both paths. To upgrade, each custom connector must be Java 17 ready, so the work to rebuild, test and republish it is required whether you stay on Mule or move to Camel. Camel routes are written in Java, YAML or XML, so Java code that already runs on Java 17 is a sensible starting point, although connector logic still has to be reworked into Camel components. Illustrative example: an estate with dozens of flows that use only built-in connectors would mostly need a runtime upgrade and regression testing, while an estate where a handful of flows depend on in-house connectors would spend most of its effort on those connectors under either option.
Before committing, confirm three things with MuleSoft and in your own environment: the support dates and accepted Java versions for Mule 4.9 LTS, the Camel release line you would adopt, and which custom connectors your teams can rebuild before August 2026. For Camel, the Apache Camel download page lists 4.22.1 LTS ending in August 2027 and 4.18.5 LTS ending in February 2027, so the chosen line sets how often you must upgrade again. Ask for a written inventory of connectors, flows and deployment targets, since the migration sequence depends on it.
What the Mule 4.6 deadline requires from your estate
Mule 4.6 LTS leaves Standard Support in August 2026, and the deadline reaches beyond the runtime itself. Java 8, custom connectors, shared libraries and the deployment model each determine how much work an upgrade to Mule 4.9 LTS or a move to Apache Camel will take. Inventory these items before you choose a path.
Standard Support end date
Mule 4.6 LTS leaves Standard Support in August 2026, so every application still on that runtime needs a planned path before then. List each Mule runtime version in use across production, staging, development and disaster recovery, because lower environments often lag behind. Confirm the exact support dates in your MuleSoft contract or with your MuleSoft account team, since your subscription terms define what support you hold.
Java 8 runtime dependency
Java 8 support ends with Mule 4.6 support, so any host still running Java 8 will fall outside vendor coverage. Check the JVM version on every runtime server, container base image and CI build agent that packages Mule applications. Build scripts and Maven profiles often pin an older JDK without anyone noticing, so search them directly rather than relying on documentation.
Custom connector Java 17 readiness
Custom connectors and Java components must compile and run on Java 17 before you can upgrade the runtime. Inventory each connector repository, its build target and its test coverage, and identify which ones have no current owner. A connector that no one maintains is usually the first item that blocks an upgrade, so record the owner for each one now.
Bundled third-party libraries
Libraries packaged inside Mule applications, such as JDBC drivers, JSON parsers and cryptography providers, can break on a newer JVM even when your own code runs cleanly. Export the dependency tree from each project's pom.xml and flag anything older than the Java 17 release your target runtime supports. Test each flagged library against the target JVM in a staging environment before you commit to a date.
Security patches after support ends
After Standard Support ends, a runtime version stops receiving security fixes, so each unpatched application becomes a standing audit finding. Choose a target that will still receive fixes for the length of your planning horizon. Apache Camel 4.22.1 LTS supports Java 17, 21 and 25 with end of life in August 2027, and LTS releases get bug and security fixes for up to a year. Confirm the lifecycle of any target you pick before you sign it off.
Deployment model per application
The upgrade path depends on where each application runs. CloudHub 2.0, hybrid deployments on customer-managed Mule servers, Runtime Fabric and Anypoint Platform Private Cloud Edition each have different upgrade and rollback steps. Record the deployment target, the owner of the infrastructure and any dependency on MuleSoft-managed services for every application, so you can sequence the work by target rather than by team.
Comparing the Mule 4.9 upgrade with Apache Camel
This table compares the paths open to a Mule 4.6 LTS estate and how each one handles the August 2026 end of standard support. Read it as a decision about the integration runtime, since WSO2 API Manager covers the API management layer separately. The main takeaway is that a Mule 4.9 upgrade keeps the current model, while Camel moves integrations to an open-source line with its own end-of-life dates.
| Option | How it meets the deadline | Trade-offs |
|---|---|---|
| Upgrade to Mule 4.9 LTS | Moves existing flows to a supported LTS line before Mule 4.6 leaves standard support and Java 8 support ends. | Smallest rewrite. Custom connectors must be Java 17 ready. Stays on MuleSoft licensing and its deployment options. |
| Apache Camel 4.22.1 LTS on Spring Boot or Quarkus | Removes the Mule runtime from the deadline. Supports Java 17, 21 and 25 with end of life in August 2027. | Flows, connectors and DataWeave are rewritten. Your team owns builds, patching and hosting. Red Hat support is optional. |
| Apache Camel 4.18.5 LTS | Also supports Java 17, 21 and 25, but its end of life is February 2027. | Shortest support window. Suits only a fast migration, and you may need a second upgrade within months. |
| Mule Community runtime | Runs Mule applications without a subscription, but it does not give the Enterprise support window. | Lacks some Enterprise features, and switching may leave configurations unsupported. Confirm each flow and ask MuleSoft about fixes. |
| WSO2 API Manager (separate decision) | Does not replace the integration runtime, so it cannot meet the Mule deadline on its own. | Covers gateway, portal and policies. Pair it with Camel or Mule behind it and decide the two halves together. |
How to deploy Apache Camel under the Mule 4.6 deadline
This sequence moves Mule integrations to Apache Camel in controlled stages, so each application is inventoried, proven on a pilot, run in parallel and cut over before any Mule runtime is retired.
Inventory Mule applications and custom connectors
Your team lists every Mule application, flow, connector, DataWeave script, scheduler and deployment target, including CloudHub, Runtime Fabric and customer-managed Mule servers. Record the Java version each runtime and custom connector builds against, since Java 17 readiness decides which custom connectors must be rewritten first. The output is a register with one row per application, its owners, its inbound and outbound systems and its migration priority. Confirm the register with the application owners and with whoever holds the Anypoint Platform licenses before moving on.
Audit Java versions and dependencies
Platform engineering checks the JDK each application and connector currently runs on, the libraries they pull in, and any Mule-only modules without a direct Camel equivalent. Mark which items would need changes under Mule 4.9 LTS and which would only move with a Camel rewrite. The output is a dependency and gap list that separates upgrade-in-place candidates from rewrite candidates. Confirm with your security team which JDK builds and base images they already approve, because a Camel target on Java 17, 21 or 25 must fit those rules.
Choose a Camel LTS line
The architecture lead selects an Apache Camel release line for production, normally a long-term support release, and records its Java support and end-of-life date. The Camel download page lists 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, while Camel 4.23.0 is a non-LTS standard release. The output is a signed decision record naming the version, the runtime (Spring Boot or Quarkus), and the review date. Confirm the choice against your own patch cadence and the Camel project's current download page before you pin any version.
Build a pilot route on Spring Boot or Quarkus
A small integration team picks one low-risk, well-understood Mule flow and rebuilds it as a Camel route in Java, YAML or XML. Spring Boot suits teams with existing Spring skills, while Quarkus suits teams that need fast startup or native compilation. The team maps each Mule connector to a Camel component, reproduces error handling and retries, and writes tests that compare message payloads from the old and new flows. The output is a running pilot with a test suite and a short list of gaps. Confirm that every connector used by the pilot is present in the Camel catalog for your version, because some Mule connectors need custom components.
Deploy to your own Kubernetes
Platform engineering packages the pilot as a container and deploys it to your own Kubernetes cluster, using Camel K where its lightweight, serverless-style model fits the workload and standard Spring Boot or Quarkus deployments where it does not. Set up configuration and secrets, health checks, logging and metrics so operations can see the route as it runs. The output is a pilot deployment with documented runbooks and a rollback path to the Mule runtime. Confirm the cluster, ingress, identity and secrets arrangements with your operations and security teams, and confirm that the cluster sits inside the network boundary your data rules require.
Run Camel and Mule in parallel
For each migrated application, the team routes a controlled share of traffic or a replayed copy of messages to the Camel service while the Mule flow stays live. Compare outputs, error rates, latency and downstream side effects, and fix differences before any consumer depends on the new route. The output is a parallel-run report per application that shows where behavior matches and where it does not. Confirm with the owners of downstream systems that duplicate processing is safe, and agree in writing who signs off on the comparison results.
Cut over each application
Once the parallel run passes its agreed criteria, the team moves the application's consumers and producers to the Camel endpoint, keeps the Mule deployment in standby for the rollback window, and monitors the new service through the first business cycles. Cutover runs one application at a time, so a fault affects one integration rather than the whole estate. The output is a completed cutover record with the approval, the monitoring results and the rollback decision. Confirm the rollback window and the change approval process with your change advisory board before the first cutover.
Retire Mule runtimes after cutover
After every application using a given Mule runtime has moved and its rollback window has closed, the team decommissions that runtime, removes its licenses or subscriptions from the plan, and archives the Mule projects, configuration and deployment records for audit. Keep the archived artifacts readable so auditors can trace past behavior. The output is a decommission record per runtime and an updated inventory showing zero remaining Mule dependencies. Confirm with your procurement and legal teams the notice terms for ending Mule subscriptions and what must be retained under your records policy.
Evidence that proves each application is ready to move
A Mule 4.6 exit is only as defensible as the records behind it. The six artifacts below connect the inventory, the target release, the test evidence, the support plan and the sign-off, so each application can be traced from its current Java and connector set to its cutover decision.
Connector inventory with Java versions
List every Mule application, its custom connectors, its Java runtime and every external system it calls. Custom connectors must be confirmed as Java 17 ready before any upgrade path, and the inventory is where that check is recorded per connector. Flag connectors with no source or no owner, because those usually decide whether an application moves in the first wave or waits. Engineering leads use this list to size work, and change boards use it to confirm nothing is left unassigned.
Dependency record for the Camel LTS target
Record the Apache Camel release each application targets, the Java version it runs on and the Spring Boot or Quarkus runtime it uses. Choose an LTS line deliberately, because LTS releases receive bug and security fixes for a longer period than standard releases. Confirm the end-of-life date for the chosen line on the Camel download page before the record is approved, since it sets the next upgrade date.
Flow behavior test results
Keep side-by-side test results showing that each migrated route produces the same outputs, error handling and retry behavior as the Mule flow it replaces. Include message payloads, transformation outputs and failure paths, not just happy-path runs. Where a DataWeave script was rewritten, store the input and expected output pairs that prove equivalence. Auditors and application owners read these results to judge whether behavior changed.
Support window and patch plan
Document the vendor support dates for Mule 4.6, the target runtime and every component in the stack, and the patch cadence the team commits to. Mule 4.6 LTS leaves Standard Support in August 2026, so the plan should show which applications are still on that line at each checkpoint. Name who applies security patches, how fast critical fixes are rolled out and who signs off when an upstream release lands during the migration.
Cutover runbook
Write a step-by-step runbook for each application covering deployment target, traffic switch, rollback trigger, data reconciliation and the owner for each step. Include the Mule endpoint shutdown, the Camel deployment on your own Kubernetes or servers, and the monitoring checks that confirm the cutover. Rehearse the rollback in a non-production environment before the production window, and keep the rehearsal log with the runbook.
Decision record for each application
Keep one decision record per application stating whether it upgrades to Mule 4.9 LTS, moves to Apache Camel, or retires. Each record should cite the connector inventory, the effort estimate from the team, the test evidence and the named approver. Internal change boards use these records to approve each move, and external auditors can trace a decision back to the evidence that supports it. The records do not establish compliance on their own, so confirm with your assessor which evidence formats they accept.
What effort each path takes and what drives it
The Mule 4.9 LTS upgrade involves less rewriting but more dependency risk, and its effort depends mostly on custom connectors. Each custom connector must build and pass tests on Java 17 before the runtime moves, because Mule 4.6 LTS leaves Standard Support in August 2026 and Java 8 support ends with it. Ask for an inventory of every connector, including its source, its owner and whether that owner still maintains it. Flows that call CloudHub-specific services need a separate check, since those dependencies do not move with the runtime. Effort rises with the number of custom connectors, the number without a maintainer, and the number of flows tied to CloudHub-only services, which you should confirm in your own environment.
The Camel path shifts most of the work into flow rewriting and DataWeave replacement. Each Mule flow maps to a Camel route written in Java, YAML or XML, and each Mule connector maps to a component from the more than 350 connectors in the Apache Camel download page listings. DataWeave scripts have no direct Camel equivalent, so each one becomes Java code, a bean or a transformation library your team selects, and each needs its own test cases. The volume of DataWeave in your estate is the strongest single driver of this path's effort. Run each rewritten route beside the Mule flow on recorded production inputs before cutover, and compare outputs field by field.
Runtime operation and team skills change on both paths. On Mule 4.9 LTS, your team keeps operating the Mule runtime under whichever deployment model you choose. On Camel, your team takes over build pipelines, Spring Boot or Quarkus packaging, Kubernetes deployment, JVM patching and monitoring that CloudHub or Runtime Fabric otherwise handle. Camel 4.22.1 is an LTS release supporting Java 17, 21 and 25 with end of life in August 2027, so plan a version cadence from the start. Mule XML and DataWeave skills transfer only in part, because Camel routes lean on Java libraries. Ask any implementation partner for a written breakdown of connector remediation, route rewriting, transformation rewriting, test automation, handover and post-go-live support.
Questions buyers ask before hiring a MuleSoft migration partner
How much does a MuleSoft migration to Apache Camel cost?
No single figure applies, because cost follows the number of flows, the complexity of DataWeave scripts, the count of custom Java connectors and the target hosting. The one-time components are the inventory and assessment, rewriting flows as Camel routes, converting transformations, replacing connectors, building the Kubernetes or VM platform, testing and cutover. The recurring components are infrastructure, monitoring, engineering time and any vendor support subscription you choose to buy, such as commercial support for the Red Hat build of Apache Camel. Ask for a line-item quote tied to a written scope that states the application count, the assumptions about custom connectors and the test approach, so you can see which lines change if the inventory grows.
How long does moving Mule integrations to Apache Camel take?
The pace is set by the number of applications, the share of custom connectors, the amount of DataWeave logic, and how many environments and approval gates each cutover must pass. Regulated teams also add time for parallel runs, evidence collection and change windows. Migrations usually run application by application, so the sequence matters: start with a low-risk integration to prove the pattern, then move shared services and the most business-critical flows last. Ask for a schedule with milestones for each application, the dependencies between them, the test exit criteria and the cutover plan, and confirm which dates depend on your own change board or security reviews.
What does the migration require from our internal team?
The work needs named owners on your side more than it needs large headcount. Each integration needs a business owner who can confirm expected behavior, an engineer who knows the source flows, access to Anypoint environments and exported assets, and a platform owner for the Kubernetes or virtual machine hosting. Security and change approvals must be scheduled early, and test data must be available in non-production environments. Teams taking over Camel routes need Java skills, and YAML or XML routes still require the same integration knowledge. Ask the partner for a responsibility matrix that assigns each task, approval and sign-off to a named role on both sides.
Can our internal team migrate without an outside partner?
An experienced internal team with Java and integration skills can migrate, but the decision depends on volume, deadlines and the skills you already have. The main risks are the time to learn Camel patterns, the lack of a tested cutover method for stateful flows, and competing priorities during the Mule 4.6 support window. A useful test is to migrate one representative integration end to end, measure the effort and decide from that result. Visual tooling such as Kaoto can help engineers new to Camel, and a fixed-scope engagement can cover specific parts, such as the first wave of flows, while your team takes over the rest. Compare the internal plan and any partner quote against the same written scope.
Does Apache Camel LTS cover the migration window?
It depends on which Camel release you choose and when your cutover ends. Camel's download page lists 4.22.1 as an LTS release supporting Java 17, 21 and 25, with end of life in August 2027, and 4.18.5 LTS with end of life in February 2027. LTS releases receive bug and security fixes for up to one year, and 4.23.0 is a non-LTS standard release listed for October 2026. Choose an LTS line whose end-of-life date sits well after your last planned cutover, and confirm the dates on the Apache Camel download page on the day you decide. Red Hat commercial support covers the Spring Boot and Quarkus runtimes, but not OSGi (Karaf) or JBoss EAP.
Does a Mule 4.9 upgrade still need Java 17 connectors?
Yes, custom connectors must be ready for Java 17 before you can upgrade, regardless of the target runtime. Start by inventorying every custom connector and each third-party connector version your flows use, then confirm each one builds and runs on Java 17 in a non-production environment. Your upgrade plan should also check that the connector versions you depend on are supported on the Mule 4.9 LTS line, since that compatibility is something to confirm with MuleSoft's upgrade documentation rather than assume. Ask the partner to show how each connector will be rebuilt, retested and approved, and whether the upgrade estimate covers the connectors you have not yet inventoried.
What happens to Anypoint features with no direct Camel equivalent?
Camel covers integration logic, connectors and enterprise integration patterns, but it does not bundle the hosted control plane, Exchange, API Manager, monitoring or Anypoint MQ. Each of those needs a deliberate replacement, such as WSO2 API Manager or Gravitee for API management, Backstage for an API catalog, OpenTelemetry-based monitoring, Apache Kafka for queued messaging and a separate secrets manager. Some features will be simpler to operate and others will need more staff time. Ask for a feature-by-feature mapping in the written scope, with each gap marked as replaced, accepted or out of scope, and a named decision owner who signs off on every gap before cutover.
How DeployOpen plans and delivers a Mule exit under this deadline
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For a Mule exit, that means inventorying what runs on Mule 4.6 before Standard Support ends, then sequencing either an upgrade to Mule 4.9 LTS or a move of integrations to self-hosted Apache Camel.
How we scope
- We inventory Mule applications, custom connectors, JDK versions and the runtime each one deploys to before any plan is drafted.
- The written scope names which flows move to Apache Camel, which stay on Mule 4.9 LTS, and which are retired.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts and a quote following from that scope.
How we build
- We rebuild or upgrade integrations on Camel routes, tested against your own endpoints, credentials and message samples.
- Custom connectors are checked for Java 17 readiness, and dependencies are pinned to the Camel LTS line you choose.
- Security testing of the rebuilt APIs and integrations can be run as part of the delivery, not left until after cutover.
How we hand over
- Each application gets a runbook covering deployment, configuration, monitoring, backup and rollback in your environment.
- Mapping documents show each Mule component and DataWeave transformation next to its Camel equivalent, with open items listed.
- Handover includes a written record of compliance-relevant controls and evidence, which your auditors assess; DeployOpen does not issue audit reports or certifications.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after cutover.
- Retainers can cover Camel LTS upgrades as each release line approaches its end-of-life date, so the next deadline does not catch you unprepared.
- Ask for the support boundary, response arrangements and upgrade cadence to be written into the scope before work begins.
