We help companies break free from MuleSoft.

Why Unmule exists

Unmule was founded because MuleSoft's pricing got so aggressive that mid-market companies started looking for exits — and there weren't many specialists to help them.

The problem isn't that MuleSoft is bad technology. It isn't. The problem is that Salesforce figured out how to turn integration middleware into a recurring six-to-seven-figure line item, with escalation clauses baked into every contract, and a pricing model that scales with your business growth whether or not you're getting proportional value. By year three of a typical MuleSoft relationship, the renewal conversation starts feeling less like a partnership and more like a shakedown.

Meanwhile, Apache Camel has been quietly doing the same work for free, since 2007. It implements the same enterprise integration patterns MuleSoft implements. It has more connectors than Anypoint Exchange. It runs on any cloud, any cluster, and any JVM. It has a healthy open-source community, production-grade tooling, and zero licensing costs. For companies that want to keep integrating systems without paying a perpetual tax to Salesforce, Camel is the answer — and has been for years.

What was missing was a credible path from one to the other. Generic integration consultancies will happily quote a rip-and-replace project, but most have never actually lived inside a production MuleSoft deployment long enough to know what they don't know. The DataWeave porting alone is enough to sink projects that weren't estimated by people who have done it before. Unmule exists to fill that gap.

Who built it

Unmule is founded by Kevin Major, who has spent the last decade building and operating MuleSoft deployments at real companies, and the last several years migrating them to Apache Camel. The case studies on this site aren't hypothetical — they're drawn from actual production systems Kevin and his team have audited, migrated, and operated in production.

Kevin's background is hands-on engineering, not management consulting. That shows up in how Unmule approaches every engagement: the first thing we do is read your codebase. Not the architecture diagrams, not the Runtime Manager dashboards — the actual Mule XML, the actual DataWeave scripts, the actual connector configs. Every migration plan we produce is grounded in what's really in the estate, not what the team thinks is in the estate. That's how you avoid surprises six months into a migration.

How we work

What we believe

A few convictions that shape how we approach every migration:

• Middleware should be invisible infrastructure, not a line item on the P&L. When integration costs start showing up in board conversations, something has gone wrong.
• Every flow written in a proprietary language is a future tax. DataWeave, custom Mule DSLs, Anypoint Exchange-hosted connectors — these all feel free when you write them and expensive when you try to leave.
• Open source doesn't mean unsupported. Apache Camel has a larger, more active community than most proprietary integration platforms. The tooling is mature, the documentation is good, and the patterns are well-understood by anyone who's done enterprise integration.
• Vendor lock-in is a choice. Every integration team is one architecture decision away from owning its own stack. The sooner you make that choice, the cheaper it is.
• A good migration improves more than just cost. Deploy speed, observability, hiring, team morale — all of it gets better when you move off proprietary middleware. The cost savings are the headline, but they're not the only reason to do this.

See a real migration

The most concrete way to understand what Unmule does is to read our anonymized case study of a 528-flow enterprise MuleSoft migration. It covers the audit, the scope, the gotchas, the target stack, and the outcome — with every number pulled from a real production system. If you're considering a migration yourself, it will tell you more about the reality of this work than any number of marketing pages.