An Australian bank received an Oracle Java proposal priced per employee across its entire workforce, far beyond the teams that actually used Java. We mapped real use, built an OpenJDK migration, and cut the exposure to what the bank needed.
An Australian bank faced an Oracle Java employee metric bill across its whole workforce. Mapping real use and migrating to OpenJDK cut the exposure to what it needed.
This case follows an Australian bank through an Oracle Java proposal. Details are anonymized, but the metric, the levers, and the outcome are exactly as run.
Oracle priced Java on the employee metric, which counts the whole workforce regardless of use. For a large bank, that number was enormous and disconnected from reality.
Oracle Java SE moved to a Universal Subscription priced per employee in 2023. The count includes every full time, part time, temporary, and contract worker, whether or not they ever touch Java.
Oracle sets out the model on its Java SE subscription pages. For a bank with a large workforce, the employee count dwarfed the population that actually ran Java.
Oracle Java exposure: as proposed versus as resolved
| Dimension | Oracle proposal | After mapping and migration | Effect |
|---|---|---|---|
| Scope | Per employee, whole bank | Real Java systems only | Scope collapses |
| OpenJDK | Counted in scope | Excluded, already free | No obligation |
| Oracle Java | Across the estate | Residual workloads only | Footprint shrinks |
| Exposure | Workforce wide bill | Specific and small | Cost avoided |
The first step was an honest inventory. We catalogued every Java runtime across servers and endpoints, then separated Oracle Java builds from OpenJDK distributions already in use.
Much of the installed base was already free OpenJDK, such as builds documented by the Eclipse Adoptium project. Those installations carried no Oracle obligation and should never have been inside the proposed scope.
With real use mapped, the bank ran a phased migration to OpenJDK on the systems that still carried Oracle Java. OpenJDK shares the same core code base, so most workloads moved with little change.
Oracle and the OpenJDK community document the shared lineage through the Java SE FAQ. The bank tested workload behavior before each cutover and kept a short list of exceptions.
The phased migration removed Oracle Java from the large majority of the estate. The residual Oracle footprint was small and specific, tied to a few workloads with a genuine dependency.
The outcome was that the bank avoided a per employee subscription scoped to its entire workforce. It paid, where it paid at all, for real and specific need rather than for headcount. Each migrated runtime was validated against the JDK release notes before cutover.
The standard advice when the employee metric proposal lands is to negotiate the per employee rate down and sign, treating the metric as unavoidable. We disagree. In roughly 30 to 40 Java engagements we ran, the employee proposal priced 5 to 20 times the population that actually used Oracle Java, and much of the installed base was already free OpenJDK wrongly pulled into scope. Negotiating the rate still leaves you paying per head for software most heads never run. The buyer side move is to inventory real use, strip OpenJDK out of the scope, and migrate the residual Oracle Java to OpenJDK so the metric never applies to the whole workforce. Change the scope, not just the rate.
Source: Redress Compliance advisory engagement file, 2024 to 2025.
The bank was quoted for every employee. It used Java on a fraction of its systems. The gap between those two numbers was the entire negotiation.
Oracle Java SE is priced per employee under the Universal Subscription introduced in 2023. The count includes every full time, part time, temporary, and contract worker, regardless of whether they ever use Java.
Because it counts the entire workforce rather than Java users. A large bank has far more employees than Java users, so a per employee subscription prices software against headcount that has no relationship to actual use.
Yes. OpenJDK distributions such as Eclipse Temurin from the Adoptium project are free for commercial use. Installations of free OpenJDK carry no Oracle obligation and should not appear in an Oracle Java proposal scope.
In most cases yes. Oracle Java and OpenJDK share the same core code base, so the large majority of workloads migrate with little change. Test each workload before cutover and keep a short exception list.
A phased migration removed Oracle Java from the large majority of the estate, leaving a small residual footprint tied to specific dependencies. The bank avoided a per employee subscription scoped to its entire workforce.
Negotiating the rate alone still leaves you paying per head for software most employees never run. The stronger move is to change the scope by inventorying real use and migrating residual Oracle Java to OpenJDK.
Begin with a full inventory of Java runtimes, separate Oracle builds from OpenJDK, and exclude the free OpenJDK from scope. Then map the remaining Oracle Java to the workloads that genuinely require it.
Migrating to a supported OpenJDK distribution removes the Oracle subscription obligation for those systems. Keep evidence of which runtimes are OpenJDK and test workloads before cutover to manage operational risk.
Oracle Java audit defense posture, the employee metric, OpenJDK exit paths, and the buyer side moves across the Oracle estate.
Used across more than five hundred enterprise engagements. Independent. Buyer side. Built for procurement leaders running the next renewal cycle.
We sit on your side when you negotiate with the major software publishers. Independent, benchmarked, and built for the renewal in front of you.
Contact Us