Die meisten Migrationsprojekte beginnen mit einer Entscheidung: von Oracle Java SE auf OpenJDK umsteigen, eine Linux-Distribution am Ende ihres Lebenszyklus ablösen oder Server in einer Private Cloud konsolidieren. Auf dem Papier wirkt der Plan meist einfach. Dann entdeckt das Projektteam Java-Laufzeitumgebungen, von denen niemand wusste, Server, für die niemand zuständig ist, und Anwendungen, die unbemerkt von einer alten Version abhängen. Zeitpläne verschieben sich, Budgets wachsen.

Vermeiden lässt sich das, indem Sie mit einer Bestandsaufnahme beginnen: einem vollständigen, faktenbasierten Inventar dessen, was tatsächlich installiert ist. Dieser Artikel erklärt, was Sie erfassen sollten, wie Sie es unter Windows und Linux erfassen, mit welchen Überraschungen Sie rechnen müssen und wie Sie aus den Ergebnissen einen Migrationsplan machen.

Warum die Bestandsaufnahme vor der Migration kommt

Eine Migration ist nur so gut wie die Informationen, auf denen sie beruht. Ohne Inventar schätzen Sie den Umfang anhand von Erinnerungen, alten Tabellen und Lizenzunterlagen – und keine dieser Quellen zeigt, was heute tatsächlich läuft.

Ein gutes Inventar liefert Ihnen drei Dinge:

• Umfang: wie viele Rechner, Laufzeitumgebungen und Anwendungen betroffen sind, damit Sie Aufwand und Kosten realistisch abschätzen können.
• Risiko: welche Systeme nicht unterstützte oder ungepatchte Versionen nutzen und welche geschäftskritisch sind.
• Zuständigkeit: wer für welches System verantwortlich ist, damit Tests und Abnahme einen klaren Verantwortlichen haben.

Außerdem schützt es Sie in Lizenzgesprächen. Fragt ein Hersteller, wie viele Installationen Sie haben, können Sie mit einem aktuellen Inventar mit Fakten statt mit Vermutungen antworten.

Was Sie erfassen sollten: Versionen, Hersteller, Pfade und Verantwortliche

Erfassen Sie für jede Java-Installation mindestens Folgendes:

• Host: Rechnername, IP-Adresse und ob es sich um einen Server, eine virtuelle Maschine oder einen Desktop-PC handelt.
• Version: die vollständige Versionsangabe, zum Beispiel 1.8.0_202 oder 17.0.10, nicht nur „Java 8“ oder „Java 17“.
• Hersteller: wer die Laufzeitumgebung erstellt hat, etwa Oracle oder eine OpenJDK-Distribution. Die Version allein verrät Ihnen das nicht.
• Typ und Pfad: ob es sich um ein vollständiges JDK oder nur um eine JRE handelt, und das Verzeichnis, in dem es bzw. sie installiert ist.
• Nutzung: welche Anwendungen oder Dienste sie verwenden, sofern sich das ermitteln lässt.
• Verantwortlicher: das Team oder die Person, die für den Rechner oder die Anwendung zuständig ist.

Erfassen Sie bei Linux-Servern zusätzlich Distribution und Version, die Kernel-Version, die wichtigsten installierten Pakete und die laufenden Dienste. So erkennen Sie, welche Server nicht nur von einer Java-, sondern auch von einer Linux-Migration betroffen sind.

Windows, Linux und Desktop-PCs: unterschiedliche Ansätze

Jede Umgebung erfordert ein etwas anderes Vorgehen. Die folgenden Befehle sind Ausgangspunkte; in der Praxis bündeln Teams sie in einem Skript und führen es mit ihren vorhandenen Management-Tools auf allen Rechnern aus.

Windows-Server

Installierte Java-Laufzeitumgebungen tragen sich häufig unter dem Windows-Registrierungsschlüssel HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft ein, aber nicht alle. Eine Suche im Dateisystem ist zuverlässiger:

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

Prüfen Sie jedes Laufwerk, nicht nur C:, denn Anwendungsserver werden oft auf einem separaten Datenlaufwerk installiert.

Linux-Server

Kombinieren Sie unter Linux den Paketmanager mit einer Dateisuche, da viele Java-Laufzeitumgebungen aus einem Archiv entpackt statt als Paket installiert werden:

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

Verwenden Sie unter Debian oder Ubuntu dpkg -l | grep -i -E 'jdk|jre' anstelle von rpm. Wenn Sie jedes gefundene java-Binary mit -version aufrufen, sehen Sie die Version und in der Regel auch den Hersteller. Die meisten JDK-Verzeichnisse enthalten außerdem eine Datei release, in der der Hersteller (Implementor) angegeben ist.

Desktop-PCs

Desktops sind der Teil des Inventars, der am häufigsten vergessen wird. Entwickler installieren eigene JDKs, und Geschäftsanwendungen bringen mitunter unbemerkt eine Java-Laufzeitumgebung mit. Da es viele Desktops gibt, nutzen Sie nach Möglichkeit das Software-Inventar Ihres Endpoint-Management-Tools und setzen nur dort ein schlankes Skript ein, wo diese Informationen fehlen.

Typische Überraschungen (gebündelte JREs, vergessene Server)

Fast jede Bestandsaufnahme fördert Dinge zutage, mit denen niemand gerechnet hat. Am häufigsten sind:

• Gebündelte Laufzeitumgebungen: Viele kommerzielle Anwendungen liefern eine eigene, private Java-Laufzeitumgebung in ihrem Installationsverzeichnis mit. Sie taucht unter Umständen weder in der Registry noch in einer Paketliste auf.
• Mehrere Versionen auf einem Rechner: Alte Laufzeitumgebungen werden bei der Installation einer neuen selten entfernt, sodass auf einem Server drei oder vier vorhanden sein können.
• Vergessene Server: Testrechner, alte Batch-Server und virtuelle Maschinen, die nie außer Betrieb genommen wurden und oft veraltete, ungepatchte Versionen nutzen.
• Unbekannte Verantwortliche: Rechner, für die sich niemand zuständig erklärt. Für sie muss vor Beginn der Migration eine Entscheidung fallen, auch wenn diese lautet, sie abzuschalten.

Vom Inventar zum Migrationsplan

Sobald die Daten erfasst sind, führen Sie sie an einer Stelle zusammen und prüfen sie gemeinsam mit den Systemverantwortlichen. Ordnen Sie die Installationen anschließend Kategorien zu:

Gruppe	Inhalt	Vorgehen
Entfernen	Laufzeitumgebungen, die nicht mehr genutzt werden	Jetzt deinstallieren, um Risiken und lizenzrechtliche Exposition zu verringern
Ersetzen	Laufzeitumgebungen, die Sie selbst verwalten	Nach Tests auf einen unterstützten OpenJDK-Build umstellen
Abstimmen	Laufzeitumgebungen, die mit Anwendungen von Drittanbietern gebündelt sind	Zuerst eine Support-Aussage des Anwendungsherstellers einholen
Klären	Alles ohne Verantwortlichen oder klaren Zweck	Verantwortlichen ermitteln oder die Abschaltung beschließen

Auf Basis dieser Gruppen können Sie einen realistischen Zeitplan erstellen: Beginnen Sie mit Systemen mit geringem Risiko, um das Vorgehen zu erproben, und gehen Sie dann mit einem getesteten Rollback-Pfad zu den geschäftskritischen Systemen über.

Wie LOGIQ Sie unterstützen kann

LOGIQ führt Discovery- und Migrationsprojekte für Java- und Linux-Umgebungen durch und nutzt dabei Skripte und Verfahren, die in realen Kundenprojekten auf Windows-Servern, Linux-Servern und Desktop-PCs verfeinert wurden. Wenn Sie Unterstützung beim Aufbau Ihres Inventars oder bei der Umsetzung in einen Migrationsplan wünschen, kontaktieren Sie LOGIQ.