Java migration cost analysis: build vs buy.

Every enterprise paying Oracle for Java SE eventually asks the same question: is it cheaper to keep paying the subscription, or to invest once in migrating to a free OpenJDK distribution? It is a classic build-versus-buy problem — an ongoing operating cost weighed against a one-time project cost. This guide lays out both sides of the ledger, works through a realistic example, and shows how to calculate the payback period so the decision rests on numbers rather than instinct.

Framing the build-versus-buy decision

The phrase “build versus buy” is slightly loose here, because both options involve running Java — the real choice is between buying a subscription from Oracle every year and building your own supported Java runtime estate on a free OpenJDK distribution. The Oracle subscription is a pure operating expense that recurs forever and grows with your headcount. The migration is a one-time capital-style project that, once complete, takes recurring Java licensing cost to zero.

That asymmetry is the whole analysis. A recurring cost compounds; a one-time cost is paid once. The question is simply how many years of subscription it takes to pay back the migration — and for most enterprises that number is startlingly small. Across more than 340 Java engagements, migration payback periods of under twelve months are common.

The cost of staying on Oracle Java

Since January 2023, Oracle prices the Java SE Universal Subscription on an employee metric: you count every full-time, part-time, temporary, and contract worker in the organisation, regardless of how many of them actually use Java. The list price is tiered, starting at $15.00 per employee per month and falling at higher volumes. A 5,000-employee company sits around $13.50 per employee per month at list, or roughly $810,000 per year before any discount.

Three features make the “stay” cost worse than it first appears. First, it scales with total headcount — hire 500 people and your Java bill rises even though Java usage is unchanged. Second, it recurs forever; there is no end date and no equity built up. Third, Oracle has a consistent record of raising renewal pricing, so the figure you model today is a floor, not a ceiling. The honest cost of staying is “today’s subscription, growing, in perpetuity.”

The cost of migrating to OpenJDK

Migration cost splits into a one-time project cost and a small ongoing cost. The one-time cost covers discovery, testing, and rollout:

• Discovery and inventory. Finding every Oracle JDK installation across servers, desktops, containers, and cloud. Tooling plus effort — see our usage tracking guide.
• Testing. The bulk of the effort. Validating each application on the target OpenJDK build through build, automated, functional, performance, and soak layers. Our testing strategy guide covers this in depth.
• Rollout. Deploying the new runtime in waves, updating base images, golden images, and CI/CD pipelines so Oracle JDK is never reintroduced.
• Project management. Coordination, stakeholder reporting, and risk tracking across the programme.

The ongoing cost is genuinely modest. OpenJDK distributions — Eclipse Temurin, Amazon Corretto, Azul Zulu, BellSoft Liberica, Microsoft Build of OpenJDK — are free. Many enterprises run them with no paid support at all. Those that want a support contract can buy commercial OpenJDK support from a vendor such as Azul or BellSoft, typically at a fraction of Oracle’s employee-based pricing because it is priced on what you actually run, not on headcount.

A worked example

Consider a 5,000-employee enterprise running roughly 1,200 Java installations across servers and desktops. The figures below are illustrative — your own numbers will differ — but the shape of the result is typical.

The migration is fully paid back inside the first year and saves over $2.2M across three years — and the gap widens every year after that, because the subscription keeps recurring and growing while the migration cost was paid once. This is the pattern behind the more than $180M in client savings recorded across our engagements.

Hidden costs on both sides

An honest analysis names the costs that do not appear on the headline line.

Hidden costs of staying

The subscription carries compliance risk: if your deployment exceeds what you have licensed, or if unlicensed Oracle JDK is running anywhere, an Oracle audit can produce a back-dated claim. There is also lock-in cost — every year on the subscription is a year the migration is deferred and the meter keeps running. And there is the uplift trajectory: renewal increases are a recurring negotiation, covered in our uplift pushback guide.

Hidden costs of migrating

Migration is not free of effort. There is the opportunity cost of engineering time spent on testing rather than features, the small risk of an edge-case finding requiring remediation, and the ongoing discipline of configuration governance to stop Oracle JDK drifting back in. None of these is large, and all are one-time or low-recurring — but a credible analysis includes them rather than pretending the project is costless.

Calculating payback period

The payback calculation is simple. Take the total one-time migration cost and divide it by the annual subscription cost you would otherwise pay:

Payback period (years) = One-time migration cost ÷ Annual Oracle Java subscription

In the worked example, $220,000 ÷ $810,000 gives a payback of roughly 0.27 years — about three and a half months. Even if you double the migration estimate to be conservative, payback is still well inside a year. Beyond the payback point, every subsequent year is close to pure saving, because the recurring cost has been eliminated.

Two refinements make the calculation more honest. Add any optional OpenJDK support contract to the “after” side, and factor Oracle’s renewal uplift into the “before” side — both adjustments tend to make migration look better, not worse, because the subscription grows and the support contract is small.

Making the decision

For the large majority of enterprises, the build-versus-buy maths points clearly toward migration: a one-time cost with a sub-year payback versus a perpetual, growing operating expense. The cases where staying can make sense are narrow — for example, a genuine technical dependency on an Oracle-commercial-only feature, or a deployment so small the subscription is trivial. Those are the exceptions to test for, not the default.

The decision should never be made on a guess. Build the inventory, scope the migration honestly, model the subscription forward with uplift, and run the payback number. When the figures are on the table, the right answer is usually obvious — and independent, buyer-side advisers can both produce the analysis and execute the migration. Our Java Migration service does exactly that, and our renew-versus-migrate guide covers the timing question.

Frequently asked questions