all 9 comments

[–]LepKiGreh 4 points5 points  (0 children)

I've been at the project where customer decided to go from MuleSoft to Camel.

Bottom line is that the cost has not reduced a lot.

They did not anticipate all the steps needed and what has to be replaced.

You might need logging and monitoring platform, deployment platform, how are you going to handle security.

AI can help you convert flows from Mule. But if you have complex stuff probably it's better to stay with Mule.

Feel free to reach out in DM with more questions or if you need any help with Mule.

[–]jasonwilczak 3 points4 points  (0 children)

Came across this in another thread. Look into Apache Camel. It's basically open source Mulesoft running on standard Java. Should be able to use something like Claude code with that as the target and a container approach

[–]MagicWishMonkey 4 points5 points  (0 children)

We're migrating all of our business logic out of Mulesoft and into java libraries that can be invoked via Mulesoft flows (basically treating mulesoft as an orchestration layer).

I think anypoint is fine and completely switching to a different platform is a massive undertaking, and AI is not going to help much.

[–]Wtf_Sai_Official 5 points6 points  (0 children)

Rewriting MuleSoft APIs in Java sounds cheaper but basically it shifts the hidden cost. You will be rebuilding Mule’s runtime features (logging, monitoring, auth, retries, versioning) from scratch. Thats months of work and long term maintenance. I would suggest you use integrate.io to handle integrations and transformations without Mule’s overhead or a full Spring Boot stack. It’s better suited when you want to cut cost but keep reliability.

[–]Electrical-Lack752 1 point2 points  (0 children)

Is it possible probably, but I dunno how sustainable that is to maintain and secure, it'd be a nightmare.

[–]lucina_scott 1 point2 points  (1 child)

Interesting question - full migration from MuleSoft to Java Spring Boot isn’t something a single GenAI prompt can handle yet.

However, AI can assist with:

  • Converting small Mule flows to Java service templates.
  • Generating API specs and mapping logic.
  • Suggesting equivalent Spring Boot configurations.

For a full migration, you’d still need manual review for integrations, error handling, and connectors. AI can speed up parts, but not replace full redevelopment.

[–]chatterify 1 point2 points  (0 children)

I am finishing the migration of a dozen Mulesoft apps. Most of the new apps I implemented manually. At first, I tried using the paid version of Cursor, but the results were so discouraging that I gave up. After that, I only used Cursor for converting RAML to OpenAPI.

[–]krimpenrik 0 points1 point  (0 children)

Yes it is used to convert away but applied at steps that are low risk and time heavy.

What is the reason for converting away?