Software modernisieren: Altsysteme ablösen, Laravel aktuell halten

Was Softwaremodernisierung praktisch heißt

Der Begriff klingt größer, als die Arbeit meistens ist. In den allermeisten Fällen geht es nicht darum, eine Anwendung neu zu erfinden, sondern sie wieder auf einen Stand zu bringen, auf dem sie gepflegt werden kann. Vier Ebenen sind dabei zu unterscheiden, und sie hängen voneinander ab:

• Die Framework-Version. Laravel selbst auf eine Fassung heben, die noch Korrekturen bekommt. Das ist der sichtbarste Teil und selten der aufwendigste.
• Die PHP-Version darunter. Häufig der eigentliche Engpass. Eine alte PHP-Version blockiert neuere Pakete, und der Hoster setzt irgendwann eine Frist.
• Die Abhängigkeiten. Fremde Pakete, die seit Jahren niemand mehr pflegt, müssen ersetzt oder übernommen werden. Diese Entscheidung fällt einzeln, nicht pauschal.
• Die Umgebung. Server, Datenbank, Deployment. Wer nur die Anwendung migriert und die Umgebung stehen lässt, hat den Termin nur verschoben.

Wenn jemand fragt, ob wir seine Software migrieren können, meint er meistens eine dieser Ebenen und weiß noch nicht, welche. Das herauszufinden ist der erste Arbeitsschritt, und er kostet weniger, als die meisten annehmen.

Der Punkt, an dem es dringend wird

Solange eine Anwendung läuft, sieht man ihr das Alter nicht an. Auffällig wird es woanders. Ein Paket lässt sich nicht mehr aktualisieren, weil es eine neuere PHP-Version verlangt. Der Hoster kündigt an, eine alte PHP-Version abzuschalten. Eine Sicherheitsmeldung betrifft eine Abhängigkeit, für die es in Ihrer Version keine Korrektur mehr gibt.

Alle drei haben eines gemeinsam. Sie kommen mit einer Frist, die jemand anderes gesetzt hat. Deshalb plant man ein Upgrade besser, als dass man es einholen lässt.

Wie wir vorgehen

Am Anfang steht die Bestandsaufnahme. Installierte Version, Abhängigkeiten, Testabdeckung, Stellen mit eigenwilligen Lösungen. Daraus wird ein Plan mit einer Reihenfolge, in der jede Etappe für sich einen Nutzen hat und die Anwendung danach läuft.

Über mehrere Hauptversionen springt niemand in einem Satz. Nach jeder Etappe wird getestet, automatisiert wo es Tests gibt und von Hand wo nicht. Kommt eine Anwendung ganz ohne Tests bei uns an, bauen wir zuerst ein Sicherheitsnetz für die Stellen, an denen ein Fehler richtig wehtut. Alles andere wäre Blindflug.

Altsysteme ablösen

Eine gewachsene Anwendung ohne Framework löst man selten mit einem großen Umschaltmoment ab. Verlässlicher ist ein Vorbau. Anfragen laufen künftig zuerst gegen die neue Anwendung, die anfangs fast alles an das Alte durchreicht. Dann übernehmen wir Bereich für Bereich, bis nichts mehr durchgereicht wird.

Auf dem Papier dauert das länger als ein Neubau. Dafür gibt es keinen Tag, an dem alles gleichzeitig funktionieren muss. Wer so einen Tag einmal erlebt hat, versteht sofort, warum wir ihn vermeiden.