An OpenJDK migration usually runs in months, not years, and the savings begin well before the final workload moves. The pace is set less by raw size than by how cleanly your estate is inventoried and how quickly vendor questions get answered.
The honest answer on timing
There is no single number, but the shape is consistent. A focused pilot proves the process in weeks. The bulk of a typical estate moves in waves over a few months. A small residual of genuinely dependent workloads is licensed narrowly and addressed over a longer horizon. Because cost falls with each wave under the per employee Universal Subscription, you start saving from the first phase rather than waiting for completion. For the full method, see the OpenJDK migration playbook pillar.
Indicative timelines by estate size
| Estate size | Pilot | Main waves | Residual |
|---|---|---|---|
| Small, focused estate | Weeks 1 to 2 | 1 to 2 months | Ongoing, narrow |
| Mid size estate | Weeks 1 to 3 | 3 to 5 months | Ongoing, narrow |
| Large, complex estate | Weeks 2 to 4 | 6 to 9 months | Ongoing, narrow |
These ranges are indicative and assume a clean inventory and an engaged team. They describe elapsed time, not full time effort, since much of a migration runs alongside normal delivery.
What actually sets the pace
Size matters less than people expect. The real pace setters are how complete your inventory is, how many workloads carry third party software that needs a vendor answer, and how much of your estate is containerized and therefore quick to rebuild. An estate that is well documented and heavy on containers can move faster than a smaller estate that is poorly mapped. The way to sort that estate quickly is covered in which workloads can move to OpenJDK today.
Why savings lead the timeline
The financial timeline runs ahead of the technical one. Every wave that moves off Oracle Java shrinks the counted footprint you have to defend, which strengthens your position at the next renewal even while later waves are still in flight. A documented, in progress migration is itself leverage, so you do not have to finish the project to start changing the negotiation. This is why a phased plan beats a single cutover, as set out in planning an OpenJDK migration in phases.
How to move faster without raising risk
Three moves compress the timeline safely. Start vendor support questions early, since written answers are often the longest pole. Group similar workloads so one proven runbook clears many at once. And keep the residual question open rather than letting a single hard dependency stall an otherwise ready wave. None of these trades speed for risk, because each still passes through the same compatibility testing before cutover.
Build the timeline on evidence
A credible schedule rests on a real inventory and a tested runbook, not on optimism. Once you have both, the waves become predictable and leadership can see savings land on a calendar. Keep dated records as you go, which both governs the program and builds the audit evidence you want with LMS reviews intensified in 2026 and running a three year lookback.
The buyer side takeaway
Expect a pilot in weeks, the main estate in months, and a narrow residual handled over a longer horizon, with savings starting from the first wave. Inventory quality, vendor responsiveness, and container coverage set the pace far more than raw size. Download the field guide below to build a realistic, evidence based timeline for your own estate.
Download the OpenJDK Migration Field Guide
A buyer side playbook for CIOs, procurement, and general counsel planning a move off Oracle Java. Trade a work email, get the guide and The Java Audit Brief.
Download guide