PHP-Migration vs. Neuentwicklung

Viele IT-Verantwortliche sind heute mit veralteten PHP-Anwendungen konfrontiert und der Frage, ob sich eine Migration auf eine neuere PHP-Version noch lohnt oder ob eine Neuentwicklung besser wäre.

Der Entscheidungsdruck steigt, da sich die Wartungsfenster derjenigen Linux-Distributionen schließen, die noch ältere PHP-Versionen auch nach dem offiziellen Support-Ende weiter warten. Beispielsweise wird die letzte Hauptversion aus dem PHP 5 Strang, nämlich PHP 5.6, seit dem 1. Januar 2019 nicht mehr offiziell vom PHP-Team mit Sicherheitsupdates versorgt. Dasselbe Schicksal ereilte bereits PHP 7.0, 7.1 und 7.21.

Will man weiterhin den Betrieb der Anwendung sicherstellen, ist der Umzug auf einen aktuellen Linux-Server und damit der Umstieg auf eine neue PHP-Version (7.4 oder 8.0) unumgänglich.

Aber wie viel kostet diese Migration? Ist eine Neuentwicklung gar sinnvoller? Dieser Artikel soll die Einflussfaktoren auf diese Entscheidung erläutern.

Kostenfaktoren PHP-Migration

Es gibt eine Reihe typischer Faktoren, die den Aufwand einer PHP-Migration bestimmen.

Kostenfaktor Umstellung MySQL Datenbankschnittstelle

Eine häufiger Aufwandstreiber ist der Austausch der alten MySQL Datenbankschnittstelle, die ab PHP 7.0 nicht mehr zur Verfügung steht. Funktionsaufrufe wie mysql_connect, mysql_query usw. sind mit den äquivalenten PDO-Aufrufen zu ersetzen. Werden die nicht mehr unterstützten Funktionen bereits an zentraler Stelle gekapselt, ist der Umstieg verhältnismäßig einfach.

Sind sie jedoch im ganzen Code direkt in Verwendung, wäre die Migration ein guter Zeitpunkt diese Kapselung einzuführen, damit ein späterer Umstieg auf eine andere Datenbankschnittstelle (z.B. um neben MySQL auch PostgreSQL zu unterstützen) kostengünstiger wird.

Kostenfaktor MySQL Syntax

Mit der Erneuerung der PHP-Version geht auch das Anheben der MySQL-Version einher. Je nachdem wie groß der Versionssprung ist, wird man auch SQL-Queries anpassen müssen, denn SQL Statements, die in MySQL 5.x erlaubt waren, können in MySQL 8 Fehler auslösen. Beispielsweise verbietet MySQL 8.0 im standardmäßigen strict-Modus inkomplette GROUP BY Klauseln. Das bedeutet, wenn eine Spalte im SELECT-Teil nicht Ziel einer Aggregationsfunktion ist, muss sie auch in GROUP BY gelistet werden. Das war in MySQL 5.x noch nicht standardmäßig der Fall.

Kostenfaktor Zeichensatz

Mit der Datenhaltung eng verbunden ist auch der verwendete Zeichensatz, der jedoch nicht nur die Daten in der Datenbank betrifft, sondern oft den gesamten Server. Es gibt nämlich durchaus noch Hosts, die über alle Schichten hinweg mit ISO-8859-1 operieren. Auch wenn die Möglichkeit bestünde moderne Linux-Server auf diesen Zeichensatz zu trimmen, so ist doch der Umstieg auf UTF-8 unbedingt zu empfehlen. Dafür sind beispielhaft zwei Gründe genannt.

  1. Jegliche Entwicklungswerkzeuge gehen in ihren Standardeinstellungen dieser Tage von UTF-8 aus. Arbeitet eine Anwendung aber noch mit ISO-8859-1, geht wertvolle Entwicklerzeit mit der entsprechenden Rekonfiguration der Werkzeuge verloren.
  2. Schnittstellen zu anderen Systemen verwenden allermeist UTF-8. Um mit diesen ordnungsgemäß kommunizieren zu können, müssen aufwendige und fehlerbehaftete Zeichensatzumwandlungen im Code der Anwendung eingebaut werden. Wieder geht wertvolle Entwicklerzeit verloren, was die Wartungskosten unnötig erhöht.

Derlei Faktoren schlagen sich also negativ auf den Entwicklungsaufwand zukünftigen Änderungen und Erweiterungen nieder.

Freilich kann die Konvertierung der Datenbank auf UTF-8 eine heikle Operation sein. Aber sie spart zukünftig Zeit und Geld und die beiden Sprichwörter sind hier sicherlich angebracht: „Wann, wenn nicht jetzt“ und „Je früher, desto besser“.

Kostenfaktor Frameworks

Ein weiterer Einflussfaktor ist, ob die Anwendung ein Framework benutzt. Tut sie das, kann man Glück haben und das verwendete Framework wird noch aktiv entwickelt. Ist das nicht der Fall, hat man großes Pech.

Im ersten Fall hängt viel davon ab, ob die Framework-Entwickler einen leicht zu gehenden Migrationspfad geschaffen haben. Außerdem muss festgestellt werden, wie stark die Anwendung mit den Framework-Klassen verwoben ist. Je stärker dies ausfällt, desto aufwendiger gestaltet sich die Umstellung.

Die Verstrickung der fachlichen Logik mit Framework-Klassen spielt auch eine Rolle, wenn das Framework nicht mehr aktiv entwickelt wird. Je loser diese Verstrickung ist, desto einfacher lässt sich das Framework im Zuge der Migration ersetzen.

Schließlich gibt es oft auch den Fall, dass gar kein Framework eingesetzt wurde, womit der Kostenfaktor Framework-Migration entfällt.

Kostenfaktor Wartungsfreundlichkeit

Zu guter Letzt beeinflusst auch die Wartungsfreundlichkeit des Source Codes den Migrationsaufwand.

  • Sind automatisierte Tests vorhanden?
  • Ist der Quellcode gut strukturiert?
  • Wurde ein einheitlicher Coding-Standard eingehalten?
  • Handelt es sich um Spaghetti-Code oder sind Anzeige-, Geschäfts- und Datenhaltungslogik sauber voneinander getrennt?
  • Wurde das DRY-Prinzip eingehalten, oder sind identische Code-Fragmente per Copy-and-paste im ganzen System verteilt?
  • Leider auch: Wurde ein ordentliches Versionsverwaltungssystem (z.B. Git) eingesetzt, oder purzeln leicht abgewandelte Kopien derselben Datei im Verzeichnisbaum der Anwendung herum?

All diese Dinge beeinflussen die Wartungsfreundlichkeit. Ist ein solche gegeben, wird die Umstellung auf eine neue PHP-Version selbstverständlich leichter.

Kostenfaktor Syntax und Methoden-Semantik

Modifizierte Syntax-Regeln und die Änderung der Semantik einzelner Standard-Methoden sind aus der Erfahrung heraus weniger oft ein Problem. Sicherlich gibt es diesbezüglich in jedem Migrationsprojekt Anpassungsbedarf, aber die Anpassungen sind in der Regel leicht umsetzbar.

Argumente für Neuentwicklung

Verglichen mit einer Migration, wird die Neuentwicklung in den allermeisten Fällen teurer sein. Die große Frage ist, um wie viel.

Um diese Frage zu beantworten, braucht es selbstredend eine ordentliche Aufwandsschätzung für die Migration. Dafür sind die oben angeführten Einflussfaktoren in einer eingehenden Analyse zu betrachten.

Eine Aufwandsschätzung ist selbstverständlich auch für die Variante "Neuentwicklung" zu treffen. Allerdings würde es zu kurz greifen, lediglich die beiden Zahlen unterm Strich zu vergleichen und einfach die billigere Variante zu wählen.

Mindestens ebenso wichtig ist, die wirtschaftlichen und technischen Rahmenbedingungen zu betrachten.

Einflussfaktor Neuaufstellung Geschäftsprozesse

Eine der wichtigsten Fragen ist, ob die Organisation die von der Anwendung abgebildeten Geschäftsprozesse ohnehin neu aufstellen möchte.

  • Möchte die betreffende Abteilung, beispielsweise aufgrund von Personalmangel, einen höheren Automatisierungsgrad erreichen?
  • Möchte Sie Prozesse digitalisieren?

Wenn solche Überlegungen ohnehin im Raum stehen, ist die Umsetzung neuer Prozesse auf der grünen Wiese oft einfacher.

Um es mit einer Analogie zu verdeutlichen: Wenn Sie einen nicht unterkellerten Bungalow geerbt hätten, und Sie sich den Wunsch eines eigenen Weinkellers erfüllen wollen würden, würde sich die Unterkellerung des Bungalows auszahlen oder wäre der Abbruch des Bungalows und der anschließende Neubau vernünftiger?

Einflussfaktor obsolet gewordene Funktionalität

Selbst wenn die dahinterliegenden Prozesse bislang nicht angezweifelt wurden, ist die Migrationsproblematik doch ein guter Zeitpunkt, um die Prozesse einem kritischen Blick zu unterziehen. Das jedoch nicht unbedingt, um Prozesse nur um der Änderung willen anzupassen, sondern vor allem um zu fragen, welche Teile der Applikation überhaupt noch verwendet werden.

Die Antwort auf diese Frage kann sein, dass viele Bereiche nicht mehr genutzt werden, weil sich die Prozesse in den letzten Jahren bereits verändert haben. Je mehr das zutrifft, desto weniger relevante Teile der Anwendung bleiben übrig, die neu zu entwickeln wären und umso geringer fällt der Aufwand für eine Neuentwicklung aus.

Einflussfaktor Änderungsfrequenz

Ein weiterer Gradmesser ist die Änderungsfrequenz. Fragen Sie sich, wie oft die Applikation in den letzten Jahren erweitert oder verändert wurde. Fragen Sie sich auch, wie viel Kosten alleine die Ausbesserung von Programmfehlern verursacht hat.

Damit eng verbunden, stellen Sie sich auch die Frage: Wie oft kam es vor, dass Änderungswünsche nicht umgesetzt wurden, weil der Aufwand zu hoch gewesen wäre? War dies häufig der Fall, könnte es darauf hindeuten, dass die Anwendung wenig wartungsfreundlich ist. Eine Neuentwicklung kann, sofern sie professionell gemacht wird, die Änderungskosten um einiges senken.

Einflussfaktor Benutzerfreundlichkeit

Wie zufrieden sind die Anwender mit der Schnelligkeit der Applikation? Wie zufrieden sind sie mit der Benutzerfreundlichkeit? Eine hohe Unzufriedenheit ist ein triftiger Grund, um die Neuentwicklungsvariante in Betracht zu ziehen, denn die rein technische Migration wird keine Linderung in diesen Punkten bringen.

Um diesen Einflussfaktor mit Zahlen zu hinterlegen, bietet sich an, die Zugriffsstatistiken des Webservers auszuwerten, um zu sehen, welche Seiten der Anwendung besonders häufig abgefragt werden. Im zweiten Schritt wird die Ladezeit mit Browser-Tools gemessen. Im dritten Schritt berechnet man die Arbeitszeit pro Jahr, indem man die hochgerechnete Anzahl der Aufrufe einer Seite mit der durchschnittlichen Ladezeit multipliziert.

Einflussfaktor Framework

Auch technische Gegebenheiten beeinflussen das Verhältnis zwischen dem Aufwand einer Neuentwicklung und dem einer Migration.

Dabei ist wieder der Framework-Aspekt anzusprechen. Ein klarer und einfacher Migrationspfad begünstigt die Neuentwicklungsoption. Dasselbe gilt, wenn sich das Auslaufen eines Frameworks abzeichnet oder bereits beschlossene Sache ist. Als Beleg, dass Framework-Entwickler durchaus mit alten Framework-Versionen "brechen" – das Framework quasi einem nicht kompatiblen Rewrite unterzogen wird – dient das Beispiel Angular und AngularJs2.

Ein weiterer technischer Einflussfaktor ist, inwiefern die Geschäftslogik und die Datenhaltungsschicht von anderen Bereichen der Anwendung getrennt ist. Eine saubere Entkopplung begünstigt selbstredend die Neuentwicklung. Hingegen wird es kostspieliger, wenn Spaghetti-Code – Anzeige-, Geschäfts- und Datenhaltungslogik sind wild miteinander vermischt – neu programmiert werden muss.

Rationale Entscheidungsfindung

Steht die Modernisierung eines Webservers an, stellt sich immer die Frage was mit den bestehenden Anwendungen passieren soll. Denn meist bedeutet der Umzug, dass diese in einer aktualisierten Laufzeitumgebung wie PHP laufen muss.

Neben der rein technischen Migration stellt die gänzliche Neuentwicklung eine überlegenswerte Option dar. Jedenfalls müssen beide Varianten sachgemäß auf die beschriebenen Einflussfaktoren hin analysiert werden.

Der nackte Vergleich der Kosten greift dabei zu kurz. Um die rational beste Entscheidung zu treffen, müssen auch die Zufriedenheit der Benutzer und was die Anwendung zukünftig zu leisten hat – Stichwort Prozesse neu denken – miteinbezogen werden.

Fußnoten

1 Siehe https://www.php.net/supported-versions.php.

2 Angular, auch Angular 2+ genannt, ist ein komplette Neuentwicklung und mit dem ursprünglichen AngularJS inkompatibel. Siehe https://en.wikipedia.org/wiki/Angular_(web_framework).