Enterprise OpenJDK migrations run nine to fourteen months, and the blocker is almost never the JDK swap. This is the program-planning breakdown: where time actually goes, and what a buyer should sequence to compress it.
Enterprise OpenJDK migrations run nine to fourteen months, and the blocker is almost never the JDK swap. This is the program-planning breakdown: where time actually goes, and what a buyer should sequence to compress it.
Two figures circulate for the same project. One source frames the exit as a 90 to 180 day effort for most enterprises. Another puts completed large-enterprise migrations at nine to fourteen months. Both are correct, and the gap between them is the single most useful thing a program owner can understand before setting a date with the CFO. The 90 to 180 day figure describes the technical work: swapping the JDK on a known, well-tooled estate. The nine to fourteen month figure describes the whole program at scale, including the part nobody budgets for, which is discovery and tooling discipline.
In 25 years negotiating with Oracle, the pattern is consistent. The vendor's technology is not the constraint. OpenJDK distributions pass the same Java compatibility tests as Oracle JDK, and roughly 80 percent of a typical US portfolio is a straight swap requiring no rewrite. What stretches a project from a quarter to a year is the estate you cannot see and the pipelines you cannot control. This subpage sits under our Oracle Java to OpenJDK migration decision and execution guide and focuses narrowly on the timeline and the program mechanics behind it.
The blocker is not the JDK switch. It is knowing what you have.
Break a nine to fourteen month program into phases and the distribution is counterintuitive. The coding is the cheap part. The expensive parts are finding Oracle Java, proving what it does, and enforcing that developers and build servers do not reintroduce it. The table below reflects Redress Compliance market experience across large migrations rather than a single published study; treat the ranges as planning envelopes, not commitments.
| Phase | Typical duration | What consumes the time | Compressible? |
|---|---|---|---|
| Estate discovery and inventory | 6 to 12 weeks | Shadow installs, embedded JDKs, filesystem crawls, reconciling ITAM blind spots | Yes, with FS crawler tooling or AI-assisted inventory (2 to 5 days) |
| Portfolio triage and dependency mapping | 3 to 6 weeks | Separating the 80% trivial swaps from the 20% with Oracle-proprietary dependencies | Partly |
| CI/CD and workstation cleanup | 6 to 16 weeks | Standardizing pipelines, fixing PATH vs JAVA_HOME, parameterizing patch cadence | Yes, if pipelines already use shared build config |
| Wave migration (dev to test to staging to prod) | 12 to 24 weeks | Canary service, dependency-graph waves, regression testing | Partly |
| Support model and rollback readiness | 2 to 4 weeks | Distribution SLA selection, patch cadence, escalation path | Yes |
Add the ranges and the arithmetic lands squarely in the nine to fourteen month window for a large estate. Note that discovery and cleanup, the two phases with almost no code in them, account for the majority of elapsed time. That is the whole thesis: this is a tooling-discipline program wearing a migration costume.
An estate sweep typically finds Oracle Java running on 15 to 35 percent of the servers a buyer assumed were on OpenJDK. That discovery gap is the single largest source of audit exposure, and it is the reason timelines slip. You cannot migrate what you have not found, and Java hides everywhere: monitoring agents, middleware, development tools, build servers, containerized workloads, and desktop applications where third-party vendors bundled a runtime you never chose.
The tooling problem is technical and specific. ITAM tools frequently report only package-install data (MSI on Windows, Pacman on Linux). Because a Java runtime is self-contained, unpacking an archive into a directory makes it fully functional with no package record at all. Azul's recommended answer is a filesystem crawler that walks every server and desktop looking for a java executable, not a package manifest. AI-assisted inventory agents now compress this further, cataloguing every application, JDK version, Oracle-proprietary extension, and dependency chain in two to five days and separating the trivial 80 percent from the dependency-heavy 20 percent. Our dedicated treatment of this problem lives at the 15 to 35 percent discovery gap.
An estate sweep finds Oracle JDK on 15 to 35 percent of servers assumed to be OpenJDK. That gap is your audit exposure.
What a buyer should do: run the filesystem crawl before you do anything else, and run it before Oracle does. Oracle's audit trigger is its own download log, and the servers you missed are precisely the ones that produce a back-charge claim. Getting a defensible inventory early does two things at once: it de-risks the migration schedule and it caps audit exposure.
The second time sink is the pipeline and the developer machine. When it goes well, it goes very well. One engineering team running Jenkins with a standardized shared library changed a single parameter in one shared build configuration rather than editing every Jenkinsfile. That is the reward for pipeline standardization done years earlier. When it goes badly, it goes badly across hundreds of repositories that each pin Java their own way.
The classic workstation trap is PATH pointing to one Java installation while JAVA_HOME points to another, producing build failures that look like migration bugs but are actually configuration drift. A second discipline problem hides in lower environments where the application is patched together with the runtime: small maintenance patches ship without JVM patch updates, so the safe move during migration is to separate or parameterize those pipelines so they always pull the latest OpenJDK patch. These are not hard problems. They are numerous problems, and volume is what eats the calendar.
The full playbook for this workstream, including the workstation image and pipeline audit, is covered in cleaning Oracle JDK out of CI/CD pipelines and developer workstations.
The proven sequence is phased by criticality: dev, then test, then staging, then production, lowest criticality first. Inside that, the wave model works. Start with a single low-risk canary service to validate the distribution, the pipeline change, and the support model. Then expand in manageable waves that follow the dependency graph, so upstream services move before the services that depend on them. This is where the 20 percent with Oracle-proprietary dependencies gets scheduled last and worked hardest.
Embedded JDKs deserve their own track. When a third-party application bundles Oracle Java, you cannot simply swap the runtime; you are dependent on the vendor's certification and repackaging cadence. Those cases carry a different risk profile and a different timeline, addressed in migrating around embedded JDKs in third-party apps. Build them into the schedule as long-lead items, not surprises.
Three support deadlines converge in 2026 and they compress the planning window for anyone who has not started. OpenJDK 8 community support ends in November 2026. Oracle Java 21's free license (the NFTC period) expires in September 2026. Spring Boot 3.5 open-source support ends in November 2026. Any of these can force a version move on top of a distribution move, which lengthens the schedule.
Work backward from the binding date. If a program needs nine to fourteen months and a deadline lands in November 2026, a serious enterprise should have started discovery no later than early 2026. If you are reading this after that point, the response is not to skip discovery, it is to buy a bridge (a short, tightly scoped Oracle subscription or a defensible hold) while you run the program properly. Rushing the estate sweep to hit a date is how audit exposure gets baked in.
The migration clock is not only a technical schedule. It is leverage. The Java SE Universal Subscription, rewritten on January 23, 2023, prices on a per-employee metric that counts full-time, part-time, and temporary staff plus the employees of agents, contractors, outsourcers, and consultants who support internal operations, regardless of whether they touch Java. List pricing runs from $15 per employee per month at the low tier down to roughly $5 at the highest, with tier boundaries at 1,000, 10,000, and 40,000 employees. Oracle's own worked example puts a 28,000-employee company at $2,268,000 per year. Many buyers saw the bill triple overnight when the metric changed, and an 8 percent annual escalation clause compounds the pain every year a team stays.
Here is the connection to the timeline. Once a migration to OpenJDK is shown as credible, settlements have landed 40 to 70 percent below Oracle's opening figure. A migration that is planned, funded, and demonstrably in flight is a fundamentally different negotiating position than a hope. The nine to fourteen month program is what makes the exit credible, which is what resets the price. Separately, buyers should test Oracle's employee count: quoted counts have run 18 to 28 percent above what a clean headcount audit can defend, and median discount from first quote to three-year signature sits between 22 and 41 percent depending on tier. For the CFO framing of this, see building the CFO business case to leave Oracle Java, and for the numbers behind each path, the three Java patterns modeled.
Settlements landed 40 to 70 percent below Oracle's opening figure once migration to OpenJDK was shown as credible.
Plan for nine to fourteen months and treat any shorter promise as conditional on a mature, standardized estate you can prove you have. Front-load discovery with a filesystem crawl or AI-assisted inventory rather than relying on package-based ITAM data, because the 15 to 35 percent you miss is exactly what generates audit and schedule risk. Give CI/CD and workstation cleanup a named owner and a real timeline; it is the discipline problem that quietly consumes months. Sequence by criticality with a canary and dependency-graph waves, and pull embedded-JDK cases forward as long-lead items.
On distribution choice, do not let it block the start: the leading OpenJDK builds are compatibility-tested equivalents, compared in Corretto vs Temurin vs Zulu vs Microsoft, and the support and rollback posture is covered in OpenJDK support and rollback risk. Finally, run the discovery before Oracle's audit function does, because the timeline that protects your project also protects your back-charge exposure, which for a 5,000-employee company found non-compliant can exceed $1.8 million across three years.
Large enterprises complete OpenJDK migrations in nine to fourteen months when measured as a full program. A narrower technical swap on a well-tooled, fully inventoried estate can run 90 to 180 days. The difference tracks estate size and tooling maturity, not the difficulty of the JDK change itself.
Because the swap is not the blocker. Discovery and tooling discipline are. Finding every Oracle Java installation across shadow installs, embedded JDKs, and CI/CD pipelines, then enforcing that developers and build servers do not reintroduce Oracle Java, consumes the majority of elapsed time. Roughly 80 percent of a portfolio is a trivial swap; the schedule is spent on the estate you cannot see.
The discovery gap. An estate sweep typically finds Oracle Java on 15 to 35 percent of servers assumed to be OpenJDK. ITAM tools often report only package-install data and miss self-contained runtimes unpacked into directories, so a filesystem crawler or AI-assisted inventory is required to get a complete, defensible picture before you can schedule the work accurately.
Three deadlines converge in 2026: OpenJDK 8 community support ends November 2026, Oracle Java 21 free licensing expires September 2026, and Spring Boot 3.5 open-source support ends November 2026. A nine to fourteen month program should have begun in early 2026 to hit a November date. If you are behind, buy a tightly scoped bridge rather than rushing discovery and baking in audit exposure.
Yes. A credible, in-flight migration to OpenJDK has reset negotiations, with settlements landing 40 to 70 percent below Oracle's opening figure. A planned and funded program is a materially stronger position than a stated intention, so the timeline is both a delivery plan and a leverage asset.
Partly. Discovery compresses dramatically with a filesystem crawl or AI-assisted inventory (days instead of weeks). CI/CD cleanup compresses when pipelines already use shared build configuration. The wave-based production rollout and the 20 percent with Oracle-proprietary dependencies are harder to shorten safely. Aim to compress the front end, not the testing and rollout.
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.
