Most migration projects start with a decision: move from Oracle Java SE to OpenJDK, replace an end-of-life Linux distribution, or consolidate servers into a private cloud. The plan usually looks simple on paper. Then the project team discovers Java runtimes nobody knew about, servers that no one owns, and applications that quietly depend on an old version. Timelines slip and budgets grow.

The way to avoid this is to start with discovery: a complete, factual inventory of what is actually installed. This article explains what to collect, how to collect it on Windows and Linux, which surprises to expect, and how to turn the results into a migration plan.

Why discovery comes before migration

A migration is only as good as the information it is based on. Without an inventory, you are estimating scope from memory, old spreadsheets and license records, and none of these reflect what is really running today.

A good inventory gives you three things:

• Scope: how many machines, runtimes and applications are affected, so you can estimate effort and cost realistically.
• Risk: which systems run unsupported or unpatched versions, and which ones are business critical.
• Ownership: who is responsible for each system, so that testing and sign-off have a clear owner.

It also protects you in licensing discussions. If a vendor asks how many installations you have, a current inventory lets you answer with facts instead of guesses.

What to collect: versions, vendors, paths and owners

For every Java installation, collect at least the following:

• Host: machine name, IP address, and whether it is a server, a virtual machine or a desktop PC.
• Version: the full version string, for example 1.8.0_202 or 17.0.10, not only “Java 8” or “Java 17”.
• Vendor: who built the runtime, such as Oracle or an OpenJDK distribution. The version alone does not tell you this.
• Type and path: whether it is a full JDK or only a JRE, and the directory it is installed in.
• Usage: which applications or services use it, if you can find out.
• Owner: the team or person responsible for the machine or application.

For Linux servers, also collect the distribution and version, the kernel version, the main installed packages and the running services. This tells you which servers are part of a Linux migration as well as a Java one.

Windows, Linux and desktop PCs: different approaches

Each environment needs a slightly different method. The commands below are starting points; in practice, teams wrap them in a script and run it across all machines with their existing management tools.

Windows servers

Installed Java runtimes often register themselves under the Windows registry key HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft, but not all of them do. Searching the file system is more reliable:

Get-ChildItem -Path C:\ -Filter java.exe -Recurse -ErrorAction SilentlyContinue |
  Select-Object FullName, @{n='Version'; e={$_.VersionInfo.ProductVersion}}

Check every drive, not only C:, because application servers are often installed on a separate data drive.

Linux servers

On Linux, combine the package manager with a file search, because many Java runtimes are unpacked from an archive rather than installed as a package:

cat /etc/os-release
rpm -qa | grep -i -E 'jdk|jre|java'
find / -xdev -type f -name java -perm -u+x 2>/dev/null

On Debian or Ubuntu, use dpkg -l | grep -i -E 'jdk|jre' instead of rpm. For each java binary found, running it with -version shows the version and usually the vendor. Most JDK directories also contain a release file that names the implementor.

Desktop PCs

Desktops are the part of an inventory most often forgotten. Developers install their own JDKs, and business applications sometimes install a Java runtime silently. Because there are many desktops, use the software inventory of your endpoint management tool where possible, and run a lightweight script only where that information is missing.

Common surprises (bundled JREs, forgotten servers)

Almost every discovery project finds things nobody expected. The most common are:

• Bundled runtimes: many commercial applications ship their own private Java runtime inside their installation directory. It may not appear in the registry or in any package list.
• Several versions on one machine: old runtimes are rarely removed when a new one is installed, so one server can have three or four.
• Forgotten servers: test machines, old batch servers and virtual machines that were never decommissioned, often running outdated and unpatched versions.
• Unknown owners: machines that nobody claims. These need a decision before migration starts, even if the decision is to shut them down.

From inventory to migration plan

Once the data is collected, consolidate it in one place and review it with the system owners. Then group the installations into categories:

Group	What it contains	What to do
Remove	Runtimes that are no longer used	Uninstall them now to reduce risk and license exposure
Replace	Runtimes you manage yourself	Move to a supported OpenJDK build after testing
Coordinate	Runtimes bundled with third-party applications	Get the application vendor’s support statement first
Investigate	Anything without an owner or a clear purpose	Find the owner, or decide to shut it down

From these groups you can build a realistic schedule: start with low-risk systems to prove the process, then move to business-critical systems with a tested rollback path.

How LOGIQ can help

LOGIQ runs discovery and migration projects for Java and Linux environments, using scripts and procedures refined in real customer projects on Windows servers, Linux servers and desktop PCs. If you want help building your inventory or turning it into a migration plan, contact LOGIQ.