MuleSoft’s 2026 Pricing Overhaul: Why vCores Are Disappearing and What Replaces Them

MuleSoft has run on the same core commercial logic since Salesforce acquired it in 2018: buy compute capacity measured in vCores, commit to a tier that gates features and support, and size that commitment upfront at the negotiating table. In 2026, that model changed for new customers, and understanding exactly what replaced it matters for anyone evaluating or renewing an Anypoint Platform agreement right now.

MuleSoft’s importance to the broader Salesforce platform has grown considerably since the original 2018 acquisition, particularly as Salesforce has leaned further into positioning integration as foundational infrastructure for Agentforce rather than a standalone API management product. That growing strategic importance is part of the context behind this pricing shift, since a product Salesforce increasingly treats as core platform infrastructure attracts a different level of commercial attention than one treated as a peripheral add-on.

The vCore Model Is Being Retired for New Deals

The shift is specific and confirmed directly against MuleSoft’s own documentation rather than industry speculation. As of 2026, new MuleSoft customers no longer purchase vCores at all. Packaging has moved to Anypoint Integration Starter and Anypoint Integration Advanced, billed on Mule Flows and Mule Messages rather than compute capacity, meaning anyone pricing MuleSoft today needs to model expected message volume rather than core count, while existing customers on the legacy Gold, Platinum, and Titanium editions remain on their prior vCore-based terms.

That distinction between new and legacy customers is the single most important fact for anyone with an active MuleSoft relationship right now. An organisation currently on a legacy vCore tier is not automatically migrated to the new model, but is very likely to encounter it at the next renewal, whether through a direct proposal to switch or through pressure created by the new packaging becoming the only option Salesforce actively sells going forward.

What the New Model Actually Costs

Real-world contract data on the new packaging remains limited given how recently it launched, but early benchmarking gives a useful reference point. Vendr’s dataset of anonymised MuleSoft deals shows pricing varying significantly based on deployment model, vCore or flow allocation, contract term, and bundled capabilities, with a median contract value that provides a useful anchor for what mid-market and enterprise organisations are actually signing rather than relying on list price alone.

Total cost of ownership analysis specific to the platform reinforces that the subscription line item, whatever pricing model it follows, is only part of the real annual spend. Independent benchmarking puts first-year total costs at two to three times the base subscription for typical mid-market deployments once implementation, specialist staffing, and add-on modules are factored in, a ratio that holds regardless of whether the underlying commercial model is vCore-based or the newer flow and message-based packaging.

Why Salesforce Made This Change

The shift away from vCores toward a usage-based model tied to flows and messages is not simply a packaging refresh. It reflects a broader pattern across Salesforce’s platform, where consumption tied directly to actual usage, rather than fixed capacity purchased upfront, gives Salesforce more room to expand revenue as customer usage grows without requiring a fresh negotiation every time. Compute-based vCore pricing put a natural ceiling on spend that a customer controlled directly by choosing how much capacity to provision. Usage-based flow and message pricing removes that self-imposed ceiling, since cost now scales automatically with whatever transaction volume actually flows through the platform.

This is worth understanding clearly before assuming the new model is simply a more modern or more favourable pricing structure. It shifts genuine cost control away from a provisioning decision the customer makes upfront and toward an ongoing usage pattern that is harder to cap deliberately without active monitoring and governance.

The Add-On Modules That Compound the Real Cost

Beyond the core platform pricing, whichever model applies, MuleSoft’s broader module ecosystem adds further cost dimensions worth budgeting for explicitly. API Manager, Anypoint Monitoring, Anypoint Security, and Anypoint DataGraph are all typically priced as separate annual subscriptions, either per environment, per core, or as flat fees, and none of them are included by default in the core Anypoint Platform subscription regardless of which packaging model an organisation is on.

Anypoint MQ, the platform’s managed messaging add-on, is a useful illustration of how these additional modules accumulate. Priced separately from the core platform, it commonly runs into the tens of thousands of dollars annually on its own for organisations with meaningful messaging volume, and it is easy to overlook during initial budgeting precisely because it sits outside the headline platform subscription figure most negotiations focus on.

Negotiating the Transition From Legacy Pricing

For organisations currently on a legacy Gold, Platinum, or Titanium vCore agreement, the renewal conversation now includes a genuine strategic choice that did not exist before 2026: stay on the legacy model as long as Salesforce continues to support it, or migrate to the new flow and message-based packaging. Neither choice is automatically correct, and the right answer depends heavily on whether an organisation’s actual usage pattern is more predictable under a fixed compute allocation or under a variable, transaction-driven metric.

Organisations with highly variable, seasonal, or rapidly growing integration volume may find the new usage-based model more closely matches actual cost to actual value delivered. Organisations with stable, predictable integration workloads that have historically run efficiently within a well-sized vCore allocation may find that predictability, and the cost ceiling it provides, is worth preserving under the legacy model for as long as Salesforce continues to honour it.

Building a Genuine Message Volume Forecast Before Migrating

Before agreeing to migrate from a legacy vCore agreement to the new usage-based packaging, building an accurate forecast of expected Mule Flow and Message volume is essential, and this is not always as straightforward as exporting current vCore utilisation data. The two metrics do not translate directly, since a single vCore’s compute capacity does not map to a fixed number of flows or messages in any simple linear way, and integration complexity, payload size, and transformation logic all affect how much message volume a given workload actually generates.

Running a genuine pilot period on the new packaging model, where feasible, or requesting detailed usage projections from Salesforce based on an accurate description of current integration patterns, is worth the extra effort before committing to a multi-year term under the new structure. A poorly modelled migration risks trading a predictable, well-understood vCore cost for a usage-based bill that turns out considerably less predictable in practice than the sales conversation suggested.

Conclusion

MuleSoft’s shift away from vCore-based pricing toward usage-based billing on Mule Flows and Messages is a genuine structural change, not a minor packaging update, and it affects new customers immediately while creating a real strategic decision for existing customers at their next renewal. The change removes the natural cost ceiling that upfront compute provisioning used to provide, replacing it with a model where cost scales automatically alongside actual transaction volume.

Organisations evaluating MuleSoft fresh should model expected flow and message volume carefully before committing to the new packaging, and organisations currently on legacy vCore terms should treat the next renewal as a genuine decision point between two meaningfully different commercial models, rather than assuming migration to the new structure is either mandatory or automatically beneficial.

 

More on the Blog