Since 2023 Oracle has sold Java SE through a single Universal Subscription priced per employee rather than per processor or per named user. A 12,000-employee group has Oracle JDK builds on 40 servers and roughly 900 laptops and plans to cut that footprint. What changed about their options, and where would copying the obvious response be a mistake?

The situation they are in

Oracle's own Java SE Universal Subscription Global Price List (dated 1 March 2023) sets the metric and the prices. "Employee" is defined as all of a customer's full-time, part-time and temporary employees, plus the employees of its agents, contractors, outsourcers and consultants who support its internal business operations — and the list states explicitly that the licensed quantity is determined by the number of employees "and not just the actual number of employees that use the Programs". Published tiers run from $15.00 per employee per month for 1 to 999, through $12.00, \(10.50, **\)8.25 in the 10,000 to 19,999 band**, $6.75, $5.70 and $5.25, with volumes above 50,000 by negotiation.

For this group the arithmetic is one line: 12,000 × \(8.25 = **\)99,000 a month, about $1.19m a year at list price**, whether Java runs on 940 machines or on four.

What actually changed

The metric was decoupled from anything architecture controls. Under a per-processor metric, the standard responses worked: consolidate, right-size, containerise carefully, retire instances. Each removed processors and each removed cost. Under an employee metric, reducing the footprint from 940 machines to 50 changes the bill by nothing, because the bill is a function of headcount.

Three consequences follow, and they are the transferable part:

1. The only architectural lever left is elimination. Cost falls at zero installs and nowhere before it, which makes this a portfolio decision, not a per-application one. Partial migration is the worst outcome: all of the work, none of the saving.
2. Discovery becomes the hard engineering problem. Finding every Oracle JDK build — including ones embedded inside vendor products, where the vendor's own licence may already cover the use — is the task, and it is the one that decides whether zero is reachable.
3. The last few installs cost as much as the first several hundred. The awkward ones are the applications nobody owns and the appliances nobody can patch, so an exit plan without a named owner for the final ten is a plan to keep paying.

What it cost them, and the general rule

The rule worth carrying out of this: before signing anything, ask what the licence metric is a function of, and whether any architectural decision moves it. A metric tied to processors, cores or instances is an engineering variable. A metric tied to employees, revenue or seats is a commercial one, and the architecture's only contribution is removal. That question belongs in the business case next to the price, and it is almost never asked.

Where copying this would be a mistake

Do not generalise to "always exit the vendor". Three cases where staying is correct:

• Small headcount. At 300 employees the same list price is $15.00 × 300 = $4,500 a month, about $54,000 a year. A migration programme touching hundreds of applications will cost more than that for several years, and the subscription is the cheaper answer.
• Support obligations you actually rely on. A regulated or vendor-certified stack where the application vendor supports only one runtime build turns a migration into an unsupported configuration. The saving is not worth an audit finding or a voided support contract.
• When the estate is about to change anyway. If the applications are being retired or re-platformed over the next 18 months, the migration work lands twice.

Common weak answers

• "Consolidate onto fewer servers." The correct instinct for the old metric and worth nothing under the new one. This is the whole lesson: a response tuned to a metric stops working when the metric changes, and nothing in the technology tells you that it has.
• "Switch to another JDK build and it is done." The build swap is the easy part. Testing, packaging, laptop fleet management, third-party certification and the unowned applications are the programme, and they are where the estimate belongs.