You do not have to move every Java workload to capture most of the saving. A partial migration moves the workloads that can move to a free OpenJDK distribution and keeps Oracle Java only where a real constraint requires it. Done well, it shrinks your exposure to a small, defensible residual without the risk of an all at once rewrite.
The instinct when a Java bill arrives is to think in absolutes: stay fully on Oracle Java, or rip it out entirely. Both extremes are usually wrong. Staying fully on the Universal Subscription means paying on your entire employee count for workloads that have free equivalents. Ripping everything out at once means betting the program on the hardest workloads moving on the same timeline as the easy ones. The partial migration sits between them on purpose. It moves everything that can move cleanly, isolates the genuine constraints, and leaves you with a small Oracle Java footprint you can either defend cheaply or carry while you solve the last few cases.
This is the default buyer side strategy for a simple reason. Since January 2023 Oracle has priced Java SE on a per employee metric that counts every full time and part time employee, every contractor, and every temporary worker, regardless of who uses Java. The cost is driven by headcount, not by how many workloads run Oracle Java. So the goal is not to touch every workload, it is to remove the dependence that forces you onto the employee metric in the first place. A partial migration that eliminates the broad dependence and leaves a narrow one changes the entire commercial conversation.
A partial migration starts with an honest sort of the estate. Most workloads fall into one of three buckets, and naming them is half the work.
The discipline is to be ruthless about the first bucket and skeptical about the third. Teams tend to over assign workloads to hold for now out of caution, and every workload parked there keeps you tied to the employee metric. Challenge each one. Is the vendor constraint real and current, or a habit from an older version? Is the feature actually used, or merely present? Most estates discover that the genuine hold for now bucket is far smaller than the first pass suggested.
Consider an anonymized financial services firm with a large, mixed Java estate. The first pass parks roughly a third of workloads as hold for now. On review, most of those turn out to be habit rather than constraint, and the real residual is a handful of applications behind a vendor that certifies only Oracle Java. The team moves the move now and move with care buckets to a free OpenJDK distribution over two phases, then carries the small certified residual on a tightly scoped Oracle agreement while it works the vendor for OpenJDK certification. The exposure tied to the broad employee metric falls to a fraction of the opening position. The figures are indicative, but the pattern, a large clean migration plus a small defended residual, is the one that consistently produces the saving.
An all at once migration concentrates risk into a single cutover. A partial migration spreads it. By moving the easy workloads first you build a proven pattern and real confidence before you touch anything hard. By isolating the constraints you give yourself time to solve them properly rather than under deadline pressure. And by keeping a small Oracle Java footprint where it is genuinely needed, you avoid the temptation to force a fragile workload onto a new runtime just to hit a date. Lower risk and lower cost usually travel together here, because the same sequencing that protects the estate also captures the saving early.
| Bucket | Typical share | Action |
|---|---|---|
| Move now | Often the majority | Migrate to a free OpenJDK distribution in early waves |
| Move with care | A meaningful slice | Sequence and test, then migrate in later waves |
| Hold for now | Usually small once challenged | Keep on Oracle Java, scope tightly, work the constraint |
The shares above are indicative and will differ by estate, but the lesson holds: the workloads that must stay on Oracle Java are almost always a minority, and the saving comes from moving the majority while defending the minority.
A partial migration leaves a residual Oracle Java footprint, and how you handle it commercially matters as much as the migration itself. The residual should be scoped to exactly the workloads that need it and priced against the smallest defensible employee envelope, not your whole organization. This is where the buyer side work pays off, because Oracle will want to price the residual as if nothing changed. A documented migration, a clear inventory, and a credible plan to remove the last dependence are what let you negotiate the residual down rather than accept the opening number.
Order the waves to capture saving early and de risk the hard parts. Lead with the move now bucket, because it proves the pattern and removes the largest block of exposure fastest. Bring the move with care workloads through in planned waves as each is tested. Work the hold for now constraints in parallel, treating each as a small project to either certify the free runtime, upgrade past the constraint, or retire the workload. Keep a tested rollback path on every wave so confidence never depends on hope. This rhythm lets a small team move a large estate while the residual keeps shrinking.
A partial migration does not only lower your subscription, it improves your standing in an audit. LMS audits intensified in 2026 with a three year lookback, and the questions center on where Oracle Java has run and across how many people. When most of your estate has moved to a free distribution and the remainder is a small, documented set, you can answer those questions with evidence rather than guesswork. The migration record and the inventory show that the broad dependence is gone and that what remains is confined and justified. That evidence is worth as much in an audit defense as it is in a renewal, because it caps the population Oracle can credibly claim against.
Two objections slow partial migrations more than any technical issue. The first is the fear of running a mixed estate, with some workloads on Oracle Java and some on a free distribution. In practice this is normal and stable, because the distributions are built from the same source and interoperate without trouble, and governance keeps the standard clear. The second is the worry that a partial result looks unfinished. It does not, when it is documented. A deliberately scoped residual with a plan to remove it is a finished position for commercial purposes, even as the last technical work continues. Naming these objections early keeps them from quietly stalling the program.
There is a third, quieter objection worth addressing: the concern that Oracle will simply price the residual as if nothing changed. It will try. The defense is the documentation. An inventory that separates free Java from genuine Oracle dependence, a record of migrated workloads, and a narrow definition of the residual are what force the conversation onto the smaller envelope. Without that evidence a partial migration still saves money on the runtime, but it does not translate fully into a lower price. With it, the partial migration becomes the basis of the negotiation.
Do not frame the choice as all or nothing. Move everything that can move to free OpenJDK, isolate the genuine constraints into a small residual, and defend that residual on a narrow employee envelope. That is how a partial migration captures most of the saving while carrying the least risk.
A partial migration is the practical heart of the larger plan. For the full method see the OpenJDK Migration Playbook. To take the strategy to its conclusion, read how we go about carving Oracle Java down to a small residual, and to understand why this work strengthens your hand at the table, see how migration becomes renewal leverage.
We can help you sort the estate, challenge the hold for now bucket, and build the wave plan that captures the saving early while protecting the workloads that need care. Book a strategy call and we will scope the partial migration for your estate.
We map your estate, isolate what truly needs Oracle Java, and build the migration that shrinks your employee envelope. Fixed Fee from 18,000 dollars or Gainshare with no risk to you.
Book a Strategy Call Get a QuoteFixed fee or gainshare, both backed by our guarantee. We sit between you and Oracle and we never take vendor money.
Get a QuoteWeekly intelligence on Oracle Java licensing moves and the buyer side defenses that work.