Procuring MuleSoft licenses or new vCores can sometimes feel like solving a riddle, especially if you are not entirely aware of the new implementation’s workloads, payload sizes, security and availability requirements and still need to decide how many vCores your organisation or your client actually needs. In my recent work as Mulesoft consultant at Devoteam, I found myself in a similar position with a client. A big enterprise with quite a bit of legacy applications or unmanaged integrations is now requiring to transform its IT infrastructure including Integration domain.
In the age of elastic scaling and CloudHub 2.0 auto-management, vCore estimation might seem like a problem of the past. But for many enterprises still running traditional Mule runtime deployments (on CloudHub, Runtime Fabric, or even on-prem environments) understanding how to manually calculate vCore requirements remains critical for capacity planning, budgeting, and architecture design.
This guide is written for solution architects, integration leads, and platform owners who want a structured, incremental, transparent approach to estimating vCores before making procurement decisions, starting from very basic calculation with full of assumptions to fine-grained, detailed one.
We’ll walk through a traditional, metric-driven estimation method using practical factors like:
- Interface count and grouping
- Architecture layer multipliers
- Payload sizes and transaction loads
- Complexity, redundancy, and operational overhead
By the end, you’ll not only have a clear Excel-based model for calculating vCores, but also a framework that you can adapt and defend in client discussions, internal reviews, or license negotiations.
Why Estimating vCores Matters
Accurately estimating vCores is more than just a licensing exercise, it’s a cornerstone of cost optimisation and performance planning in MuleSoft implementations. Underestimating vCores can lead to resource bottlenecks, degraded performance, and unplanned downtime during peak loads. Also you may miss out the achievement of ‘economies of scale’ because of potential ‘Volume Pricing’. It’s not the end of the world of course; you can always procure additional licenses. However, depending on your organisation’s procurement process, this may introduce delays and potentially postpone project timelines. Overestimating, on the other hand, can inflate licensing costs and reduce the ROI of your integration platform.
A well-grounded estimation ensures that your infrastructure scales predictably with business demand and that your APIs perform consistently under production stress. It also helps you align deployment models (CloudHub, Runtime Fabric, or on-prem) with real-world workloads rather than guesswork.
For architecture teams, a repeatable estimation model creates transparency in budget discussions and helps justify MuleSoft costs to stakeholders. And for clients, it provides confidence that the platform investment directly maps to measurable performance needs.
In short, thoughtful vCore estimation bridges the gap between technical design and commercial reality, ensuring that every integration is both scalable and cost-effective.
Calculation Approach with Metrics from Simple to More Complex
Simple
For the simplest approach we will only use a few metrics:
- vCore Multiplier Avg.: Average vCores would be used for the applications. This number can be chosen with your experiences and it can vary. My past clients or companies mostly use 0.1 or 0.2 vCore applications and seldomly 1 vCore (with CH2 now 0.5 vCore also comes into the picture). Therefore, I put this multiplier as 0.18.
- Interface: A single data integration between 2 systems. This is the least you can have, an approximate or exact number of interfaces (single type of data exchange).
- Three Layered Architecture Multiplier: Three-layered API architecture suggests System APIs, Process APIs, and Experience APIs; separating data access, business logic, and user interaction. Since in some of the cases you may not need all the three layers and also the reusability of process and system layers I put this as 2.5.
- Interface Groups per Product or Applications: We can group/bundle interfaces in an application following a logic of a Product or System. For example, we can group all the interfaces that inbound SAP in one application (if possible) on a System Layer and create couple of Process Layer to also bundle the Products like Warehouse and HR or Processes like Order or Quote or Invoice. Sizes of payloads and frequency of the calls have a quite an effect putting a number on this. If you have such information, good! If not, then we should rely our previous experience again and make some assumptions. I would divide this into two: Mid Term and Long Term; because while you are setting something new, you would be creating whole range of integrations and most of them generic and/or master data like Sales Order, Customer, Quote, Product, Warehouse, Invoice etc. But deep in the trail, you will start adding new integrations in the same apps like ValidateQuote, Discounts, CheckProduct, CheckCustomer, Delivery, TransportStatus etc. That will increase the interface/integration count per app. My experience says average in the mid term (6 months to 2 years) it would be 4. In the long term it would be average 7. Please be advised, this is purely my experience and it is not exact science, but it will definitely give your organisation or client an idea about the process.
Calculation
This approach can be used if you have minimal information about the implementation. Here is the calculation:
‘Min Req vCores’= ((vCore Multiplier Avg) * (Interface) * (Three Layered Architecture Multiplier)) / (Interface Groups per Product or Applications)
So in case you have 30 interfaces to be transformed in the first year, you need: (0.18 * 30 * 2.5)/4 = 3.375 vCores at least. Please bear in mind that we didn’t include High Availability requirements, Security Requirements, Complexity etc. We will also include them in the next steps.
Wrapping Up – Part 1
Estimating vCores doesn’t have to be a guessing game. By starting with core parameters like interface count, layered architecture, and grouping by products or applications, you’ve already built the foundation for a more structured and transparent approach to MuleSoft sizing.
This initial model helps you think critically about how integrations consume compute power and how vCores translate to tangible capacity. Even at this stage, it can guide early-stage procurement, budget discussions, and high-level architecture planning with confidence.
In the next part, we’ll expand this framework to include real-world factors such as integration complexity, average payload size, HA/DR multipliers, and operational overhead, bringing your estimation closer to what enterprises use in production planning.
Until then, treat this model as your baseline calculator, a starting point to spark meaningful conversations between architects, project managers, and procurement teams about what your MuleSoft landscape truly needs.
Join the Conversation
If you found this framework useful, stay tuned for Part 2, where we’ll dive deeper into real-world vCore estimation, factoring in integration complexity, payload sizes, HA/DR configurations, and operational overheads.
I’d also love to hear how you approach MuleSoft sizing in your projects. Every organisation tackles this challenge a little differently. Share your perspective or connect if you’d like to compare models and best practices. Let’s make vCore estimation a little less mysterious, one formula at a time.