Nine to fourteen months, and almost none of it is code. This is the delivery plan behind the number: the phases, the gates that set the pace, and the freeze arithmetic that decides how many waves fit in a year.
Nine to fourteen months is the honest planning envelope for an enterprise OpenJDK migration, and almost none of it is spent changing code. This is the delivery plan behind the number: the phases, the governance gates that set the pace, and the freeze arithmetic that decides how many production waves fit in a year.
Two numbers circulate for the same project and both are correct. One frames the exit as a 90 to 180 day effort. The other puts completed large enterprise migrations at nine to fourteen months.
The short number describes the technical work on a known, well tooled estate. The long number describes the whole programme, including the parts that are pure organizational latency. This page is about the long number, because that is the one you sign up to.
White Paper · Oracle Java
The buyer side route out of the Java SE subscription. Read it free.
Because they measure different things. One measures the runtime swap on an estate that has already been inventoried and standardized. The other measures the programme from the day someone asks the question.
The 90 to 180 day figure is real, and it is achievable, but it rests on four assumptions that most enterprises cannot satisfy on day one.
Score your own estate against those four honestly. Each one you fail moves you toward the upper end of the envelope, and failing the third or fourth on its own usually adds a quarter.
The engineering is a quarter. The other three quarters are discovery, approval, and waiting for other organizations to answer a letter.
Six phases, and the two with almost no code in them consume more than half the elapsed time. Plan each phase against an exit artifact rather than a date, because a date with no artifact behind it slips silently.
Phases, durations and the artifact that closes each one
| Phase | Typical elapsed | What consumes the time | Exit artifact |
|---|---|---|---|
| Discovery and inventory | 6 to 12 weeks | Shadow installs, embedded runtimes, container images, reconciling asset management blind spots | A signed inventory naming distributor, build number, install date and host purpose per instance |
| Triage and dependency mapping | 3 to 6 weeks | Separating the straightforward swaps from the workloads with a real dependency | A wave plan ordered by the dependency graph, with the hard cases named |
| Standard and distribution decision | 2 to 5 weeks | Writing the runtime standard, agreeing patch cadence, passing architecture review | An approved runtime standard and a named primary and fallback build |
| Pipeline and workstation cleanup | 6 to 16 weeks | Build agents, base images, developer machines, path and environment drift | Every new build produced on the target runtime, with the intake blocked |
| Wave migration through the environments | 12 to 28 weeks | Change windows, soak time, approval cycles, regression evidence per wave | Production running the target runtime with rollback retired |
| Decommission and evidence close | 2 to 6 weeks | Removing the last installs, capturing the evidence pack, serving contractual notice | A dated evidence file that proves what ran, where, and until when |
Add the ranges and the arithmetic lands in the nine to fourteen month window. Note that discovery and cleanup, the two phases with the least engineering in them, account for the largest single block.
Because a Java runtime leaves no reliable installation record. An estate sweep typically finds Oracle Java on 15 to 35 percent of servers a buyer believed were already on OpenJDK.
Most asset tools report package installation data, the Windows installer database or the Linux package manager. A Java runtime unpacked from an archive into a directory is fully functional and completely absent from both.
The answer is a file system crawl that looks for a Java executable on every server and every managed endpoint, then reads the release file next to it. That is a different exercise from a software inventory report, and it is the one that produces a defensible number.
The full treatment of this problem, including what the crawl should collect, sits in the discovery gap and shadow installs guide.
Record distributor, exact build number, install date, patch level and host for every instance before anything is removed. Those five fields are what bounds a retroactive claim.
Deleting a binary first destroys the only evidence that limits how far back a claim can reach. Run the crawl before Oracle's audit function does, and keep the output as a dated file.
Six to sixteen weeks, and the spread is decided entirely by how your pipelines were built years ago. This is the workstream that most often has no owner and therefore no end date.
An estate whose pipelines reference a shared build configuration changes one parameter in one place. An estate where several hundred repositories each pin their own runtime changes it several hundred times.
The full playbook, including the capture order that protects your evidence, is in cleaning Oracle JDK out of pipelines and developer workstations.
The ones that meet monthly. A gate that takes two hours of review but sits in a board that meets once a month costs four weeks of elapsed time, and most programme plans record it as two hours.
Governance gates, owners and realistic lead times
| Gate | Artifact it wants | Meets | Elapsed cost |
|---|---|---|---|
| Architecture or design authority | Runtime standard and distribution decision record | Monthly | 2 to 6 weeks, once |
| Security approval or exception | Patch cadence commitment, trust store position, vulnerability handling | Weekly or on demand | 2 to 4 weeks, once |
| Third party vendor certification | A written statement supporting the target runtime | Vendor's own cycle | 4 to 16 weeks, per vendor |
| Change advisory board | Test evidence, rollback plan, blast radius | Weekly | 10 business days, per wave |
| Operational acceptance | Runbook, monitoring, support routing for the new runtime | Per wave | 1 to 3 weeks, per wave |
| Regulatory validation, validated estates only | Qualification evidence package per system | Per wave | 4 to 12 weeks, per wave |
Two rows on that table are per wave rather than once, and they are the rows that multiply. A programme with fifteen waves and a ten business day change cycle has spent thirty weeks in approval before anyone writes a line of configuration.
It is the only gate where you have no lever at all. You cannot escalate a vendor's certification queue and you cannot buy your way past it in most cases.
Send every request in week one, with a specific question: does the vendor support release X of the application on a HotSpot OpenJDK build of the same Java version, and will it confirm that in writing. Vague questions get vague answers slowly.
Between twelve and twenty for most enterprises, and that single number usually decides the end date. Work it out before you promise anything, because it is arithmetic rather than opinion.
That produces twelve to twenty waves. Divide your application count by that number and you have the bundle size each wave has to carry, which is the honest test of whether your plan is real.
Move through the environments by criticality: development, then test, then staging, then production, lowest criticality first. Inside that, start with one low risk canary service that validates the distribution, the pipeline change and the support routing together.
Then expand along the dependency graph so that upstream services move before the services that consume them. The workloads with a genuine Oracle dependency are scheduled last and worked hardest.
Applications that bundle their own runtime cannot be swapped by you at all. You are dependent on the vendor's repackaging cadence, which is covered in migrating around embedded JDKs in third party applications.
Desktop and end user Java is the other long pole. Repackaging, a replacement for anything using the old browser launch model, and user acceptance testing add three to six months, and it is the phase most often left until it is too late to move.
In six places, and five of them are foreseeable in week one. The weeks below are the ranges we have seen added to a plan that was otherwise sound.
The six common overruns and what they cost
| Overrun | Weeks added | How to avoid it |
|---|---|---|
| Vendor certification requested late | 4 to 12 | Send every request in week one, in parallel with discovery |
| Desktop Java population found late | 12 to 24 | Include managed endpoints in the first crawl, not the second |
| Discovery re run after missing container images | 3 to 6 | Scan the registry and the base image layers, not only running hosts |
| A freeze window that was not in the plan | 4 to 12 | Build the change calendar in week one and get it signed by change management |
| Distribution reselected mid programme | 6 to 10 | Decide against a written specification, not a brand preference |
| Test environment contention | 4 to 8 | Book environment slots at wave planning, not at wave start |
The standard advice is to begin with a pilot on a low risk service, prove the approach, then plan the rollout. We disagree with the ordering, and it is the single most expensive sequencing mistake we see. A pilot is useful and it is not the critical path. The critical path runs through third party vendor certification, which is pure waiting, cannot be accelerated by adding people, and gates the very last wave of the programme. Every week you spend proving something you already know before you post those letters is a week added directly to the end date. Send the certification requests in week one, run the pilot in parallel, and accept that the pilot will tell you what the binary comparison already told you.
Four, and only two of them are Oracle's. Work backward from whichever lands first, because that is the date the plan has to hit.
Do not compress discovery to hit it. An incomplete inventory converts a schedule miss into an audit exposure, and the second costs more than the first.
Buy a bridge instead: a short, tightly scoped position that holds while you run the programme properly. The decision framework for that choice sits in the Oracle Java to OpenJDK migration decision guide, and the fallback posture in OpenJDK support and rollback risk.
A funded, staffed, in flight programme is a different negotiating position from a stated intention, and Oracle prices the difference. The schedule is a commercial asset as well as a delivery plan.
The Java SE Universal Subscription is priced per employee across the organization rather than per Java user. That metric is what makes the migration worth financing, and it is also what makes a partial migration worthless.
Say it once and design around it: finishing 95 percent of the estate on schedule saves nothing, because the remaining five percent keeps the whole workforce in scope. Completion is the only milestone that changes the invoice.
The five year comparison of subscribing, migrating fully and running a hybrid is modelled in the three Java migration patterns, and the finance framing is in the CFO business case.
Source: Redress Compliance advisory engagement file, 2024 to 2025.
Nine to fourteen months measured as a full programme, from the day the question is asked to the day the last Oracle install is gone. A narrower technical swap on a fully inventoried, well tooled estate can run 90 to 180 days. The difference is estate size and tooling maturity, not the difficulty of the runtime change.
Because the swap is not the critical path. Discovery, governance approval and waiting for third party vendors consume most of the elapsed time, and only the first is under your control. Roughly eighty percent of a portfolio is a straightforward swap, so the calendar goes on the estate you cannot see.
A third party vendor certification request sent after the pilot rather than in week one. It is pure waiting, it typically takes 4 to 16 weeks, and it gates the final wave, so the delay lands directly on the end date. The second biggest is a desktop Java population discovered in month six.
Twelve to twenty for most enterprises. A year has 52 weeks, and quarter and year end freezes, peak trading freezes and holiday clustering typically remove 12 to 20 of them, leaving 32 to 44 usable change weeks. Each wave needs its approval lead time plus a soak period, so two to three weeks each.
The front end, yes. Discovery compresses from weeks to days with a proper file system crawl, and pipeline cleanup compresses sharply if your builds already use shared configuration. The wave rollout and the workloads with genuine Oracle dependencies are much harder to shorten safely, so compress the front end and leave the testing alone.
Buy a bridge rather than rushing discovery. A short, tightly scoped commercial position holds the risk while the programme runs properly, and it costs less than an incomplete inventory that turns a schedule miss into an audit exposure. Compressing the estate sweep is how back charge exposure gets baked in.
Yes, materially. A funded, staffed programme with an approved standard and a running pilot is a credible alternative, and Oracle prices credible alternatives differently from stated intentions. Show the budget line and the pilot, and keep your raw inventory and wave calendar to yourself.
No, and this is the most important scheduling fact on the page. The subscription is priced per employee across the whole organization, so a single remaining Oracle install keeps the entire workforce in scope. Ninety five percent complete and one hundred percent complete produce the same invoice.
Oracle now audits Java SE on employee count, not installs, which can multiply the bill several times over. How to defend the notice and exit to OpenJDK.
Gated with a work email on the download page. No sales follow up you did not ask for.
Get the White Paper →
500+ enterprise clients. 11 vendor practices. Industry recognized. One conversation can change what you pay for the next three years.
One buyer side briefing a week. Renewal signals, audit moves, and the levers that work. No vendor spin.
