Introduction
The conversation about enterprise Java runtimes usually starts as a technical one: which specification, which container strategy, which cloud. Within two quarters it becomes a financial one. A CIO inherits a WebLogic or WebSphere estate built over a decade, asks what it actually costs to run, and discovers the answer is not in any single document. The license schedule covers the headline fee. The support renewal adds a percentage. The audit, when it arrives, applies the real logic of the pricing model and produces a number that can exceed the original license fee.
This post is about that number. Specifically, it is about why the pricing models on the incumbent application servers, Oracle WebLogic, IBM WebSphere, and Red Hat JBoss EAP (Enterprise Application Platform), are structured so that the cost is hardest to see at the moment the buyer has the least room to negotiate. Those vendors’ pricing models have become a risk surface in their own right, separate from the technical merits of the runtime, and a CFO or CIO evaluating a runtime change should weigh that risk alongside the headline cost.
The alternative on the table is transparent per-vCore pricing, where the unit is a virtual core, dev and test are charged at the same unit price, and the cost surfaces at the purchase order. The argument below is structural: transparent per-vCore pricing changes where and when the cost becomes visible, a bigger shift than any single line-item saving.
The headline license is the smallest line
Consider what an enterprise actually pays to run a legacy application server.
| Cost layer | How it shows up |
| Core-factor or PVU multiplication | Oracle applies a processor core-factor (an Intel Xeon core carries a 0.5x factor, so each physical core counts as half a license). IBM charges 70 to 120 PVUs per Intel core , depending on processor model. The headline per-processor price is multiplied by a factor the buyer has to track per chip. |
| Sub-capacity compliance tooling | IBM requires the ILMT for PVU sub-capacity billing. Misconfiguration reverts the account to full-capacity billing. The tooling itself is an operational cost and an audit liability. |
| Separately licensed dev and test | On the Oracle and IBM models, non-production environments require their own licenses. A typical enterprise pays for the same capacity twice, once for production and once for the environments that exist only to support it. |
| The support surcharge | Oracle sets first-year technical support at 22 percent of the net license fee, then reprices it annually with a further uplift commonly reported in the 4 to 8 percent range. Five annual payments compound to 119 to 129 percent of the original license fee, and the crossover holds even at a zero percent uplift, where five years still reaches 110 percent. |
| Edition upsells and adjacent products | WebLogic clustering requires Enterprise Edition. The data grid on WebLogic is Coherence, a separate Oracle product. Access management for OAuth2 requires OAM (Oracle Access Manager), another product. Each capability that an application needs is a distinct purchase and a distinct operational failure domain. |
| The JDK as a separate contract | The JDK underneath the application server is a separate contract with its own metrics and renewal calendar, even when both come from the same vendor, as with Oracle WebLogic licensing and the separately metered Oracle Java SE Subscription. Estates that have moved JDK support to a third party reconcile two vendors on top of that. |
None of these lines is hidden in a literal sense. Each appears somewhere in the contract stack. The structural problem is that no single document totals them, and the effect is that the total is hardest to compute at renewal, when switching costs are highest and the buyer’s leverage is lowest.
The audit is a finance problem, not an IT problem
The reason the final number surfaces at the audit is that the pricing models are enforced through audit. Once that is true, the audit becomes a financial risk surface that belongs on the CFO’s map, not the CIO’s.
The data on this is concrete. A 2025 global survey of 500 IT asset and software asset management professionals, conducted by Dimensional Research for the IT Asset Management (ITAM) Forum and Azul, and published in July, found that 73 percent of enterprises had undergone an Oracle Java audit in the preceding three years. That figure covers Java SE, but the audit organization and the methodology are the same ones that reach WebLogic estates. The audit muscle is one team applying one playbook across the Oracle portfolio.
| Vendor | Pricing model | Audit mechanism |
| Oracle WebLogic | Processor core-factor licensing; 22 percent first-year support surcharge, repriced annually thereafter; dev and test licensed separately | Per-employee and per-processor audit model; 73 percent of Oracle Java users audited in three years |
| IBM WebSphere Application Server (traditional WebSphere, or tWAS) | PVU pricing, 70 to 120 per Intel core | Mandatory ILMT; misconfiguration reverts to full-capacity billing across the entire estate rather than the sub-capacity footprint |
| Red Hat JBoss EAP | Per-core-pair pricing, unpublished | Bundled into broader Red Hat footprint negotiations; MicroProfile gated behind a second EAP XP (JBoss EAP expansion pack) subscription |
The IBM side has a documented case that makes the asymmetry concrete. The ISAM Group, a licensing-defense consultancy, published an anonymized state-government audit spanning IBM’s broader product portfolio that opened with a $60 million finding and settled near $150,000 after audit defense. The case spans IBM products broadly and is not WebSphere-specific. Even with that scope caveat, the shape of the case is instructive: the initial finding was four hundred times the settlement, which means the audit process itself, not the underlying usage, was where most of the financial exposure lived.
What changes when cost surfaces at the purchase order
The structural alternative is to price the application server per virtual core, include dev and test in the subscription, bundle the data grid and clustering, and supply the JDK from the same vendor. The unit of billing is a vCore. The cost is visible at the purchase order because there is no multiplication factor to apply later and no separate compliance tooling to maintain.
| Dimension | Incumbent model | Per-vCore, one-vendor model |
| Billing unit | Processor core-factor (Oracle), PVU (IBM), per-core-pair (Red Hat) | Virtual core |
| When the real cost surfaces | At the audit or the renewal | At the purchase order |
| Dev and test | Licensed separately | Same per-vCore rate as production, no separate SKU |
| Data grid and clustering | Separate product (Coherence, eXtreme Scale) or higher edition | Built in (Hazelcast) |
| Compliance tooling | ILMT mandatory on IBM; audit exposure on Oracle | None required |
| JDK vendor | Separate vendor and contract | One vendor for the JDK and the application server; the JDK is a separate product, not bundled |
| Audit exposure | A reconstruction of what ran where, at what multiplication factor | A count of provisioned vCores against the subscription |
The last row is the one that belongs on the CFO’s risk register. An audit under the incumbent model means reconstructing, months or years after the fact, what ran where and at what multiplication factor. That reconstruction is a project, and a finding is what it produces. An audit under the per-vCore model is a count of provisioned virtual cores against the subscription, a reconciliation.
The one-vendor point matters here for a reason that is not the obvious one. The obvious argument for buying the JDK and the application server from one vendor is procurement simplicity. The risk argument is stronger: when the JDK and the runtime come from the same vendor, there is no inter-vendor dispute at audit about which product was responsible for which deployment. The perimeter of what the subscription covers is coextensive with the perimeter of what the vendor supplies.
Why a runtime change is the cheaper modernization path
A CIO weighing a runtime change will hear an internal objection: the migration itself costs money, so why move off a runtime that is paid for? The answer is that the incumbent is perpetually being paid for, at a rate that is hardest to see at renewal, and the pricing model is the mechanism that keeps it that way.
The same logic applies to the modernization mandate that often triggers the runtime conversation. A Spring Boot rewrite of a Jakarta EE estate runs a median of $1.2 million per portfolio (a reported range of $500,000 to $5 million) over 18 months across 142 analyzed migration projects, with a reported 70 percent success rate. This post reads that figure as roughly a 30 percent cost-overrun risk, since the source reports a success rate without itself defining failure as running over budget or timeline. That cost is the rewrite budget, a documented figure separate from the licensing exposure this post is about; the same source page also models Spring Boot’s own licensing savings and break-even timeline, an argument this post does not adopt or dispute. A runtime change that avoids the rewrite and replaces the audit-exposed pricing model addresses two cost surfaces at once.
The customer outcomes are consistent with this. Hermes, now Evri, migrated off IBM WebSphere via GlassFish to Payara Server and relocated to the T-Systems Open Telekom Cloud, reacheding production 100 days ahead of schedule with a 30 percent performance improvement, outcomes tied to moving off an incumbent pricing model onto a transparent one.
What to do this quarter
Three actions follow, sized to different roles in your organization.
For the CFO. Ask for two numbers from your current application-server vendor: the total amount paid across all line items, including support surcharges, separately licensed dev and test, and any adjacent products, over the last three years; and the total exposure the audit model could assess against your current deployment if the reconciliation were run today. The gap between those numbers and the headline license fee you negotiated is the cost of the incumbent pricing model. Compare that against a per-vCore quote sized to your actual production footprint, with dev and test priced the same as production, no separate product to buy.
For the CIO or CTO. Run a parallel evaluation during your current renewal term. Deploy one standard Jakarta EE application to the namespace-matched Azul Payara version, unchanged, and run it alongside production. The technical question, “does the application behave identically?”, answers itself in days. The commercial question, “what does the same workload cost under a different pricing model?”, answers itself in the quote. The renewal deadline is the forcing function, but the decision should rest on data pulled from your own code.
For the Procurement leader. Read the contract clauses that govern audit, sub-capacity reconciliation, and support uplift on your current application-server agreements. The risk in those clauses is the risk this post is about. A per-vCore subscription with one vendor for the JDK and the runtime, with no compliance tooling requirement, is typically negotiated without those clauses.
That is a procurement outcome with a direct line to the contract terms themselves.
If you want a direct conversation, contact Azul. The team that supplies the JDK and Azul Payara works with some of the largest financial, government, and industrial workloads in production. They can map your estate to a per-vCore quote and a phased migration plan, and the quote is built on the same per-vCore unit that appears on the purchase order.
The pricing model is the risk
The headline license fee on a legacy application server is a fraction of what the runtime actually costs. The rest of the cost is structured to surface at the audit or the renewal, and the audit itself has become a financial risk surface that finance leaders should track alongside any other vendor-concentration risk.
Transparent per-vCore pricing changes who carries the audit risk and when the cost becomes visible, a bigger shift than any single line-item saving. The CIO who treats the runtime decision as a technical one and leaves the CFO out of it is leaving the most expensive part of the conversation unmanaged.
The pricing model is the risk, and the choice is whether to keep carrying it.
