Lift & Shift: Von alten Dachböden und neuen Wolken

Keiner weiß mehr so genau, was sich darin befindet – alte Schätze, kaputte Geräte oder Dinge, die längst niemand mehr braucht. Genau so fühlte es sich an, als unsere Mitarbeiter Robert und Syahrul vor der Aufgabe standen, eine monolithische Altanwendung in die Google Cloud Platform (GCP) zu überführen.

Die Software war ein verschachteltes System aus PHP 7.4, Java 8, Python 2.7, PostgreSQL und einer betagten Elasticsearch. Alles eng miteinander verzahnt – und kaum dokumentiert. Schnell wurde klar: Eine punktuelle Modernisierung war wie der Versuch, auf dem Dachboden nur eine Kiste zu entstauben, ohne den ganzen Raum zu betreten. Nach intensiven Gesprächen mit unserem langjährigen IT-Berater Wolfgang fiel die Wahl auf ein pragmatisches Lift & Shift. Also: alles nehmen, in die Cloud tragen – und dann sortieren.

Software-Archäologie statt eines sauberen Übergabeprotokolls

Die Sache hatte nur einen Haken: Niemand hatte den Dachboden seit Jahren betreten. Der ehemalige Entwickler war nur noch sporadisch erreichbar, die Dokumentation? Fehlanzeige.

Also packten Robert und Syahrul die Taschenlampen aus und wurden zu Software-Archäologen. Sie durchforsteten alte Codefragmente, entdeckten „verwaiste“ Datenbanktabellen, tote Codepfade und schwer verständliche Abhängigkeiten – und dokumentierten alle Entdeckungen und Schätze penibel.

Zwischen Tests, Netzwerkregeln und alten Elasticsearch-Versionen

Parallel begannen sie mit der technischen Umsetzung: Anpassungen an VMs, Berechtigungen und Netzwerkregeln wurden vorgenommen, damit das System stabil in der GCP betrieben werden konnte. Eine Stolperfalle: GCPs eigene Elasticsearch-Dienste verlangten PHP 8.2 – doch die Anwendung war auf PHP 7.4 festgenagelt. Die Lösung? Eine eigene Elasticsearch-Instanz außerhalb der GCP-Services.Auf der GCP wurde die neue Anwendung zunächst zum Test und zum Vergleich mit der laufenden Altanwendung bereitgestellt. So konnten potenzielle Probleme früh erkannt und ausgebessert werden. Andreas aus dem Requirements Engineering sorgte währenddessen für die Koordination zwischen dem IKS-Team, dem Kunden und weiteren Partnern. Wolfgang blieb als Berater eng an Bord.