Bestehende PHP-Software übernehmen und weiterentwickeln

Kommt Ihnen eine dieser Lagen bekannt vor?

• Der Entwickler ist nicht mehr erreichbar, und niemand kennt den Aufbau der Anwendung.
• Der Hoster kündigt die Abschaltung einer PHP-Version an, auf die Ihre Anwendung angewiesen ist.
• Eine fachlich kleine Änderung wird seit Monaten verschoben, weil die Folgen niemand abschätzen kann.
• Auswertungen liefern Zahlen, die sich nicht erklären lassen.
• Die Anwendung funktioniert — aber es gibt keine Sicherung, deren Wiederherstellung je geprobt wurde.

In allen diesen Fällen ist die erste Frage nicht, was eine Weiterentwicklung kostet, sondern was überhaupt vorliegt. Jede Aufwandsaussage davor wäre geraten.

Was wir dabei übernehmen

• Bestandsaufnahme mit schriftlichem Befund: technische Grundlage, Aufbau, Datenhaltung, sicherheitsrelevante Stellen, Betrieb.
• Aktualisierung der Grundlage auf eine PHP-Version mit Sicherheitsaktualisierungen, einschließlich der verwendeten Bibliotheken.
• Schrittweise Ablösung einzelner Bereiche, während die Anwendung weiterläuft.
• Technische Übernahme der Betreuung, wenn der bisherige Ansprechpartner wegfällt.
• Datenbereinigung dort, wo der Befund zeigt, dass gespeicherte Werte der Oberfläche widersprechen.
• Einrichtung von Sicherungen und Überwachung — und mindestens eine geprobte Wiederherstellung.

Wie eine Modernisierung abläuft

Der Weg ist in Etappen geschnitten, weil eine Anwendung im Tagesgeschäft nicht für Monate stillstehen kann. Nach jeder Etappe ist ein Zustand erreicht, in dem man aufhören könnte.

Drei mögliche Ergebnisse — und keine vierte Antwort

Nach der Bestandsaufnahme gibt es genau drei ehrliche Antworten:

• Weiterentwickeln: Der Aufbau trägt, die Grundlage lässt sich aktualisieren, Änderungen sind zu überschaubaren Kosten möglich.
• Schrittweise erneuern: Die Anwendung bleibt in Betrieb, Bereiche werden nacheinander abgelöst. Das ist der häufigste Weg.
• Neu bauen: Wenn Aufbau und Datenhaltung so beschaffen sind, dass jede Änderung mehr Risiko als Nutzen bringt.

Die dritte Antwort braucht eine Begründung mit Fundstellen, keine Geschmacksfrage. Ein pauschales „das muss neu" ohne Prüfung verkauft ein Projekt, keine Lösung.

Was wir dafür brauchen

• Den Quelltext, möglichst mit seiner Versionsgeschichte.
• Einen Zugang zu einer Umgebung, in der sich die Anwendung starten lässt — nicht zwingend die Produktivumgebung.
• Den Aufbau der Datenbank. Ein Auszug der Struktur genügt meist; echte Datensätze sind nicht nötig.
• Eine Person, die die fachlichen Fragen beantworten kann. Code zeigt, was passiert, nicht warum.

Was wir ausdrücklich nicht brauchen, sind Zugangsdaten zu Produktivsystemen per E-Mail. Für Zugänge gibt es sichere Wege, und wir fragen nur ab, was für die Prüfung nötig ist.