This site is also available in:
API Management · Migration · Best Practices
Moving Away from MuleSoft:
What Integration Really Costs
What case studies from France, Switzerland, and the United Kingdom show, and what Swiss institutions should keep in mind when replacing a system.
Licenses that scale with volume, pricing models that are difficult to predict, and a platform that leaves little room for other standards: Many IT decision-makers are familiar with this pattern. Gravitee calls it the “integration tax.”
In this article, we summarize what Gravitee has published on this topic, how we interpret these statements, and what this means for institutions in Switzerland. Important: All figures are based on manufacturer specifications and not on independent testing.
Background
The “Integration Tax” in Three Symptoms
In his article “How to Reduce Your MuleSoft Integration Tax,” Gravitee describes typical cost drivers. Based on our project experience, we can clearly identify three of them:
- The cost model scales with volume. More APIs and more calls automatically lead to higher licensing costs, even if the value per API decreases.
- Dependence on proprietary tools. Flows, transformations (DataWeave), and the deployment model are closely integrated with the platform.
- Little room for new patterns. Event streaming, Kafka, MCP, or agent-to-agent communication can only be incorporated into the model with additional effort.
Case Studies
What Gravitee Reports
Gravitee has published the following key metrics in case studies. They provide guidance but are not a substitute for your own business case.
77%
Lower licensing costs at AÉSIO Mutuelle (health insurance, France)
91%
lower annual costs at an anonymous financial institution (USD 500,000 instead of USD 45,000)
75%
Lower infrastructure costs at Swiss Post
| Case | Initial Situation | Result (according to Gravitee) | MuleSoft Reference |
|---|---|---|---|
| AÉSIO Mutuelle | No central API platform; MuleSoft is used only to a limited extent | 77.25% lower licensing costs, 58 APIs in production | Yes, limited |
| Financial Institution (anonymous) | MuleSoft license with high annual costs | From USD 500,000 to USD 45,000 per year | Yes |
| Insurer (anonymous) | MuleSoft commitment of $8 million, approximately 300 APIs | Migration to Gravitee without any delays | Yes |
| Swiss Post | Licensing costs rose in line with volume | 75% lower infrastructure costs, 130 REST and 830 streaming APIs | No |
| Michelin | Isolated networks, high security requirements | Over 660 REST APIs in operation, 230 of which are managed via Gravitee | No |
Source: Gravitee case studies and blog post. Not all of these cases involve MuleSoft replacements; the last two demonstrate Gravitee in action to address licensing cost pressures in general.
Our assessment: The figures are impressive, but not directly comparable. The contractual basis, volume structure, and measurement time vary from case to case. At AÉSIO, MuleSoft was used only to a limited extent. Always base your calculations on your own volumes.
Classification
Three layers, not one product
The most common misconception about a MuleSoft replacement: people treat it as a simple replacement of a single product. In reality, there are three layers involved, and Gravitee covers only one of them.
| Layer | Typical artifacts | Target image |
|---|---|---|
| API Management and Gateway | API Policies, Portals, Subscriptions | Gravitee APIM, Event, and Kafka Gateway |
| Integration Logic | DataWeave transformations, flows, connectors | New services or process engines, such as Camunda, CIB Flow, or Spring Boot |
| Identity and Access | OAuth Providers, Clients, Roles | Access Management, Keycloak, or Existing IAM |
This breakdown is an ONLU assessment based on practical project experience.
Gravitee replaces the gateway and management components. The integration logic must be rebuilt or migrated separately. This is the main driver of effort, which vendor case studies rarely mention.
Procedure
Migration in Four Phases
Gravitee estimates that migrations take anywhere from about three months to a year, with a phased transition and no downtime. This is consistent with our experience when parallel operation is planned.
- 1. Inventory. Identify all APIs, flows, consumers, and volumes, and sort them by criticality and effort.
- 2. Target Vision and Pilot. Migrate two to three representative APIs; measure latency, performance, and security.
- 3. Parallel operation. Migrate consumers in waves; both platforms will run side by side.
- 4. Shutdown. Plan contracts, deadlines, and termination dates well in advance so that the cutover aligns with the contract term.
Conclusion
What Swiss Institutions Should Take Away from This
- Check the cost model first. Does the price scale linearly with the success of your APIs? If so, it’s worth considering an alternative calculation.
- Thinking About Standards and Kafka. Event streaming and agent scenarios support the use of an open gateway layer.
- Evaluate the integration logic separately. This is usually where the most effort is required.
- Clarify the operating model. On-premises, OpenShift, or the cloud: Data storage and FINMA requirements are key factors.
Free Dossier
All 8 case studies in detail
11 pages: architecture diagram, key metrics, five patterns, review questions, and a process model. Enter your email address, and we’ll send you the PDF.
By submitting this form, you consent to receiving the dossier and occasional industry updates. You can unsubscribe at any time. See our Privacy Policy for details.
Conversation
Considering a MuleSoft replacement?
We support institutions with inventory, business case, target architecture, and pilot projects across all three layers.
Sources: Gravitee, “How to Reduce Your MuleSoft Integration Tax” (gravitee.io/blog/how-to-reduce-your-mulesoft-integration-tax) and case studies at gravitee.io/case-studies. All figures are based on manufacturer data as of October 13, 2026.
