Wenn "läuft doch" zum Risiko wird: Die stille Modernisierung einer gewachsenen Software

Die gefährlichste Aussage in der IT ist nicht "das funktioniert nicht". Es ist "das funktioniert doch". Denn dahinter verbirgt sich oft ein System, das zuverlässig seinen Dienst tut – und gleichzeitig auf einem Fundament steht, das niemand mehr anfassen will.

Die Kowada GmbH ist heute in erster Linie IT-Dienstleister für mittelständische und große Unternehmen, häufig aus dem Banken- und Versicherungsumfeld. Die Webentwicklung, aus der das Unternehmen einmal hervorgegangen ist, ist daneben zu einem kleineren Geschäftsfeld geworden. Kleiner heißt für uns aber nicht: mit geringeren Ansprüchen. Ein gutes Beispiel dafür liefert eines unserer langjährig betreuten Projekte aus genau diesem Bereich.

Eine Verwaltungssoftware, die für Sportverbände den kompletten Spielbetrieb organisiert – Spielpläne, Ergebnisse, Mannschaftsmeldungen, über mehrere Bezirke und Saisons hinweg. Ein System, das regelmäßig von Sportvereinen genutzt wird und bei dem ein Ausfall nicht "ärgerlich", sondern für den laufenden Spielbetrieb ein echtes Problem ist. Es lief stabil. Es lief zuverlässig. Und es lief auf einem technischen Unterbau, dessen Ablauf sich längst abzeichnete.

Wenn die Grundlage altert, ohne dass es jemand merkt

Die Software basierte auf Java 8, einer Java-EE-Generation, die inzwischen konsequent durch ihren Nachfolger Jakarta EE ersetzt wird, und auf Bibliotheken, deren aktuelle Versionen mehrere Jahre zurücklagen. Für die Nutzer änderte sich dadurch zunächst nichts. Für uns als Betreiber schon: Sicherheitsupdates für die verwendeten Komponenten liefen aus, neue Entwickler mussten sich in einen zunehmend veralteten Stack einarbeiten, und jede neue Anforderung wurde ein Stück schwerer umzusetzen, weil das Fundament nicht mehr mitwuchs.

Das ist die Falle, in die viele über Jahre gewachsene Systeme tappen: Solange nichts sichtbar kaputtgeht, gibt es scheinbar nie den richtigen Zeitpunkt für eine Modernisierung. Bis der Zeitpunkt dann von außen aufgezwungen wird – durch eine Sicherheitslücke, einen nicht mehr verfügbaren Server, oder schlicht dadurch, dass sich niemand mehr findet, der die alte Technik warten will.

Wir wollten diesem Zeitpunkt zuvorkommen.

Migrieren, nicht neu bauen

Die naheliegende Reaktion auf ein gealtertes System ist oft: "Bauen wir es neu." Bei einer Software, die seit Jahren im produktiven Einsatz ist und deren Regeln – Spielsysteme, Punktrunden, Sonderfälle einzelner Bezirke – über lange Zeit gewachsen sind, ist das selten der richtige Weg. Ein Neubau bedeutet, jahrelang gesammeltes Fachwissen erneut zu erarbeiten, mit allem Risiko für neue Fehler, die im alten System längst ausgemerzt waren.

Wir haben uns deshalb für den unspektakulären, aber deutlich robusteren Weg entschieden: das Fundament austauschen, während das Haus stehen bleibt. Java 8 wich Java 17. Der komplette Umstieg von javax.* auf die Jakarta-EE-10-Namensräume wurde durchgezogen. Der Anwendungsserver wurde auf die aktuelle Generation gehoben, die Datenbank-Anbindung Hibernate von Version 5 auf Version 6 aktualisiert, das Oberflächen-Framework PrimeFaces von Version 11 auf Version 15. Für die Vereine und Verbände, die die Software täglich nutzen, sollte von alldem im besten Fall nichts zu spüren sein.

Grün in der Testsuite heißt nicht: fertig

Automatisierte Tests sind für uns in jedem Projekt Pflicht, unabhängig von dessen Größe – auch hier liefen 362 Tests nach jeder Änderung automatisch mit. Nach dem Wechsel auf die neuen Bibliotheken waren alle 362 grün, der Code kompilierte sauber. Trotzdem galt die Migration an diesem Punkt für uns ausdrücklich noch nicht als abgeschlossen.

Der Grund: Unit- und Integrationstests bilden naturgemäß nur die fachliche Logik ab, für die sie geschrieben wurden – nicht das Zusammenspiel von Anwendungsserver, Bibliotheken und Datenbank beim tatsächlichen Start des Gesamtsystems. Deshalb gehört bei uns zu jeder größeren Migration ein realer Testlauf gegen eine produktionsnahe Datenbank, bevor wir irgendetwas als fertig betrachten.

Genau dieser Testlauf förderte sieben Probleme zutage, die in der Testsuite naturgemäß unsichtbar geblieben waren: ein Logging-Mechanismus, der Fehler künftig lautlos verschluckt hätte, weil ihm eine einzelne Zusatz-Bibliothek fehlte. Eine neue Version einer internen Bibliothek, die beim Server-Start in eine Endlosschleife lief. Eine Datenbank-Anbindung, die plötzlich explizit gesagt bekommen musste, mit welchem Datenbank-Dialekt sie es zu tun hat. Und, am aufwendigsten: gut tausend Datenbankabfragen im Code, die unter der alten Bibliotheksversion anstandslos funktionierten, von der neuen, strengeren Version aber zu Recht abgelehnt wurden.

Das ist für uns kein Sonderfall, sondern Standard: Automatisierte Tests sind eine notwendige, aber nie eine hinreichende Bedingung für Produktionsreife. Deshalb gehört der reale Testlauf unter realistischen Bedingungen bei uns zu jedem Migrationsprojekt dazu – unabhängig davon, ob am Ende ein Kernbanksystem oder eine Portal-Anwendung für einen Sportverband steht.

Das unsichtbare Detail: der vergessene Baustein

Ein Fund verdient besondere Erwähnung, weil er zeigt, wie tückisch gewachsene Systeme sein können: Irgendwann, Jahre zuvor, war eine kleine Zusatzkomponente für ein Bedienelement der Oberfläche eingebaut worden – nicht über die reguläre, automatisch verwaltete Paketverwaltung, sondern als einzelne Datei, still und leise ins Projekt gelegt. Jedes automatisierte Werkzeug, das im Zuge der Migration systematisch alle Namensräume im Quelltext aktualisiert hat, ist an dieser einen Datei vorbeigelaufen – weil sie eben kein Quelltext war, sondern fertig kompilierter Programmcode.

Solche blinden Flecken sind der eigentliche Grund, warum Modernisierungsprojekte länger dauern, als eine reine Versionsnummer vermuten lässt. Man findet sie nicht durch Nachdenken, sondern nur, indem man das System tatsächlich anfasst.

Was am Ende steht

Nach dieser Arbeit läuft die Software auf einem Fundament, das für die kommenden Jahre wieder tragfähig ist: aktuelle Java-Version, aktueller Anwendungsserver und aktuelle Kernbibliotheken. Für die Vereine und Verbände, die die Software nutzen, hat sich nichts verschlechtert. Im Gegenteil: Direkt im Anschluss an die Modernisierung konnten wir bereits neue fachliche Funktionen ausliefern, die auf dem alten Stand deutlich aufwendiger umzusetzen gewesen wären.

Das ist am Ende der eigentliche Punkt: Eine Modernisierung ist nicht der glamouröse Teil eines Softwareprojekts. Sie bringt keine neue Funktion, die man den Nutzern zeigen kann. Aber sie ist die Voraussetzung dafür, dass in einem Jahr, in fünf Jahren, überhaupt noch jemand guten Gewissens neue Funktionen bauen will.

Fazit: Wartung ist keine Nebensache

Wenn du für ein System verantwortlich bist, das seit Jahren zuverlässig läuft, ist genau das der richtige Moment, einmal ehrlich auf sein Fundament zu schauen – nicht erst, wenn ein Sicherheitsvorfall oder ein ausgelaufener Support-Zeitraum dich dazu zwingt.

"Es läuft doch" ist kein Zustand, auf den man sich verlassen sollte. Es ist eine Frist, die irgendwann abläuft.

Du betreust selbst ein gewachsenes System – ob Kernanwendung oder Kundenportal – und bist nicht sicher, wie tragfähig sein Fundament noch ist?

Sprich uns an. Wir schauen es uns gemeinsam mit dir an, bevor es jemand anderes für dich tun muss.