How long does a Java migration actually take?

The honest answer to “how long does a Java migration take” is: less time than most enterprises fear, and more time than most enterprises leave themselves. Moving off Oracle Java to a free OpenJDK distribution is rarely a technically difficult project — but it is a project, with discovery, testing and a phased rollout that cannot all be compressed into the final fortnight before an Oracle renewal. This article sets out a realistic timeline, phase by phase, so the move can be planned against a date rather than rushed against a deadline.

Why the timeline is a licensing question, not just a technical one

A Java migration’s schedule is governed by one external date: your Oracle Java SE subscription renewal. Migration delivers its financial benefit only when it lets you decline that renewal — and that requires every Oracle JDK installation to be removed, or moved onto a genuinely free licence, before the current term ends. A migration that finishes a month after renewal has cost you another full subscription year, which on the employee metric can be six or seven figures.

For that reason the timeline always works backwards from the renewal date, not forwards from today. Across 340+ Java licensing engagements, the single most common scheduling mistake we see is enterprises treating migration as a technical task that can start “whenever the team has capacity” — then discovering, three months from renewal, that there is not enough runway to finish. Anchor the plan to the contract, and the rest of the schedule falls into place.

The five phases of a Java migration

Every migration, whatever its size, moves through the same five phases: discovery and inventory, planning and distribution choice, testing, phased rollout, and decommissioning and validation. The phases do not change — only their duration scales with the size and complexity of the estate. Understanding what each phase contains is what turns a vague “a few months” into a defensible plan with dates.

Two of the five phases — testing and rollout — are the long, variable ones, and both can be run in parallel across application teams to compress the calendar. The other three are shorter and largely sequential. A migration that respects this sequence rarely surprises anyone; one that tries to skip discovery almost always does.

Phase 1: Discovery and inventory — 2 to 4 weeks

You cannot migrate what you cannot see. Discovery builds a complete inventory of every Java installation in the estate: which physical and virtual hosts, which versions, whether each is Oracle JDK or an already-free OpenJDK build, which licence governs it (BCL, OTN or NFTC), and which applications depend on it. Container images, CI/CD agents, developer laptops and embedded appliances all count.

For a small, well-documented estate this can be done in one to two weeks using software asset management tooling and scripted scans. For a large, fragmented, multi-region estate it can take four weeks or more, because the hard part is not the scan — it is reconciling what the scan finds with which business application owns it. Discovery is also the phase that quantifies the prize: it tells you exactly how much Oracle-licensable Java you are about to eliminate.

Phase 2: Planning and distribution choice — 1 to 2 weeks

With the inventory in hand, planning is short. The main decisions are: which free OpenJDK distribution to standardise on (Eclipse Temurin, Amazon Corretto, Azul Zulu and Microsoft Build of OpenJDK are the common choices); whether to buy a commercial OpenJDK support contract for mission-critical systems; how to sequence the rollout by risk; and what the rollback criteria are for each wave.

This phase also produces the risk-ordered roadmap — low-risk, standard applications first, complex or vendor-supplied applications last. Most enterprises complete planning in one to two weeks. It is worth resisting the temptation to over-analyse the distribution choice: all mainstream OpenJDK builds compile from the same source and pass the same compatibility tests, so the decision is about support and tooling fit, not about Java itself.

Phase 3: Testing — 3 to 8 weeks

Testing is the longest variable phase. Each application is run on the chosen distribution in a non-production environment and exercised through its normal test suite. Because OpenJDK distributions implement the same Java SE specification as Oracle JDK, the overwhelming majority of applications pass unchanged on the first attempt.

The duration depends almost entirely on application count and on how much of the test process is automated. An estate with strong automated regression suites can test dozens of applications a week; one that relies on manual user-acceptance testing moves slower. The crucial point is that testing parallelises — ten application teams can test simultaneously. Plan three to eight weeks, and treat any application that fails as a scoped remediation task rather than a reason to pause the whole programme.

Phase 4: Phased rollout — 4 to 12 weeks

Rollout replaces Oracle JDK with the free distribution in production, wave by wave. Low-risk segments go first and prove the process; business-critical systems follow once confidence is established. Each wave moves through non-production to production with monitoring in place and a rollback path ready.

For a small estate, rollout can be four to six weeks. For a large global estate with change-management windows, freeze periods and regional coordination, it can run to twelve weeks or longer — not because the work is hard, but because the change calendar only allows so many production changes per window. This is the phase where realistic scheduling matters most: rollout cannot be compressed by simply working harder; it is gated by change governance.

Phase 5: Decommissioning and validation — 1 to 2 weeks

The final phase removes every remaining Oracle JDK binary and proves it. A full re-scan of the estate should return zero Oracle JDK installations; any that remain are tracked to closure. The result is documented — a dated, evidenced record that the estate is Oracle-Java-free.

This phase is short but it is not optional. It is the step that actually closes Oracle audit exposure: an environment with no Oracle JDK present has no licensable Java for Oracle to claim. Skipping validation leaves a handful of forgotten installations that can resurface in a future audit and undermine the entire programme. One to two weeks of disciplined verification protects the savings the other four phases delivered.

Realistic totals by enterprise size

Combining the phases, here are the totals we see most often in practice. These assume the migration is properly resourced and that testing and rollout are run in parallel across teams.

Estate size	Java installations	Typical total
Small	Under 500	6–10 weeks
Mid-size	500–3,000	3–5 months
Large / global	3,000+	6–12 months

The variable is rarely the Java itself. It is the number of distinct applications to test, the maturity of the change process, and how cleanly the estate was documented before discovery began.

What slows a migration down — and what speeds it up

Migrations slow down for predictable reasons: an unmapped estate that makes discovery a forensic exercise; long change-freeze periods that throttle rollout; embedded or vendor-supplied applications that bundle their own Java and need supplier confirmation; and decision paralysis over which distribution to adopt.

They speed up for equally predictable reasons: a clean, current inventory; an estate managed through containers or configuration management, where the Java version is a single line of config; parallel testing across application teams; and a clear executive mandate that the migration is happening, which removes the endless “should we?” debate. The fastest migrations are not the ones with the cleverest engineers — they are the ones with the clearest decisions.

Working backward from the renewal date

Put it together with a worked example. Suppose your Oracle Java SE subscription renews in nine months. A mid-size estate needs three to five months of migration work, so you have comfortable runway — but only if you start now. Block the phases on a calendar: discovery in month one, planning in month two, testing across months two to four, rollout across months four to seven, decommissioning in month eight. Month nine is a buffer, not a workspace.

The discipline is to count backwards from the contract date and add a buffer, never to count forwards from today and hope. If the arithmetic shows you cannot finish in time, you have two honest choices: accelerate by adding resource and parallelism, or plan a single short bridging renewal and migrate cleanly rather than catastrophically. Either way, the renewal calendar — not optimism — drives the plan.

Frequently asked questions

How long does it take to migrate off Oracle Java?

Typically 6 to 10 weeks for a small estate, 3 to 5 months for a mid-size one, and 6 to 12 months for a large global estate. The variable is rarely the Java itself; it is the volume of discovery and testing and the maturity of the change process.

Can a Java migration be completed before our subscription renewal?

Usually yes, if it starts early enough. Work backwards from the renewal date, allow a buffer, and block each phase on a calendar. A migration that finishes after renewal costs another full subscription year.

What is the longest phase of a Java migration?

Testing and phased rollout. Both scale with the number of applications. Testing can be parallelised across teams to compress the schedule; rollout is often gated by change-management windows.

Do we have to migrate everything at once?

No. A phased rollout is safer and faster to plan. Low-risk segments move first and prove the process before business-critical systems follow.

What happens if we run out of time before renewal?

You either renew Oracle Java for another term or take a short bridging renewal and finish the migration cleanly. Starting early enough avoids the choice entirely, which is why the timeline anchors to the contract date.

Conclusion

“How long does a Java migration take” is the wrong question to ask first. The right question is “when does our Oracle subscription renew, and how much runway does that leave us?” A migration is a sequence of five well-understood phases whose total duration is predictable once the estate is sized. What is not forgiving is the calendar: finish before renewal and the migration pays for itself many times over; finish after it and you have bought another year of a subscription you no longer need. Size the estate, block the phases, count backwards from the contract date, and the timeline stops being a source of anxiety and becomes a plan.