Der Entwickler ist weg — so übernimmt man eine PHP-Anwendung.

Zuerst: Zugänge.

Bevor irgendjemand den Code ansieht, muss klar sein, wer worauf Zugriff hat. Die Liste:

Laufen Domain oder Server auf den Namen des früheren Entwicklers, ist das der dringendste Punkt — noch vor jeder technischen Frage. Eine Domain, die ausläuft, oder ein Server, der wegen unbezahlter Rechnung abgeschaltet wird, beendet die Anwendung sofort (Domain umziehen).

Code und Daten sichern.

Als Nächstes eine vollständige Sicherung: alle Dateien der Anwendung, die Datenbank, Konfigurationsdateien, hochgeladene Dateien. Abgelegt getrennt vom Server — so dass ein Ausfall des Servers die Sicherung nicht mitnimmt.

Diese Sicherung ist der Ausgangspunkt für alles Weitere. Mit ihr lässt sich eine Testumgebung aufbauen, ohne die laufende Anwendung anzufassen (Backups).

Bestandsaufnahme.

• PHP-Version und Server-Umgebung (PHP-Versionen).
• Framework und Version, oder Eigenbau.
• Abhängigkeiten und ihr Pflegestand.
• Struktur: Wo liegt was, wie hängt es zusammen?
• Datenbank: Tabellen, Größe, Beziehungen.
• Zeitgesteuerte Aufgaben und Hintergrundprozesse.
• Schnittstellen nach außen.

Punkt sechs wird oft übersehen: Viele Anwendungen haben Cronjobs auf dem Server, die nirgends dokumentiert sind — Berichte, Datenabgleiche, Aufräumarbeiten. Fallen sie bei einem Umzug weg, merkt man es erst, wenn etwas fehlt.

Risiken bewerten.

Die Bestandsaufnahme ergibt eine Liste mit Risiken. Typische Funde:

• Veraltete PHP-Version ohne Sicherheitsupdates.
• Datenbankabfragen ohne Schutz gegen eingeschleusten Code.
• Zugangsdaten im Code, womöglich in einem öffentlichen Verzeichnis.
• Keine Sicherungen oder ungetestete.
• Abhängigkeiten mit bekannten Lücken.

Die Risiken werden nach Dringlichkeit sortiert: Was kann sofort Schaden anrichten, was ist ein Problem in einem Jahr (Sicherheit)?

Sicherheitsnetz.

Bevor geändert wird: Versionsverwaltung einrichten, damit jede Änderung nachvollziehbar ist. Eine Testumgebung aufbauen, in der man gefahrlos arbeiten kann. Und für die wichtigsten Abläufe Tests, die das heutige Verhalten festhalten.

Das klingt nach Aufwand, bevor etwas passiert. Es ist der Aufwand, der verhindert, dass bei der ersten Änderung etwas Unerwartetes kaputtgeht (Modernisieren).

Den Code verstehen.

Fremden Code zu lesen ist eine eigene Fähigkeit. Ich gehe meist von außen nach innen vor: Welche Seiten gibt es, was passiert bei einem Klick, welche Dateien werden geladen, welche Datenbankabfragen laufen? So entsteht ein Bild der Anwendung, ohne jede Zeile lesen zu müssen.

Werkzeuge helfen: Protokolle, Fehlersuche Schritt für Schritt, Analyse der Abhängigkeiten. Und Gespräche mit den Menschen, die die Anwendung täglich nutzen — sie kennen die Sonderfälle oft besser als jeder Code.

Dokumentation aufbauen.

Was beim Verstehen herauskommt, wird festgehalten: Aufbau, Abläufe, Zugänge, Server, Cronjobs, Schnittstellen, bekannte Eigenheiten. Kurz und praktisch, nicht als Handbuch.

Diese Dokumentation ist das, was beim früheren Entwickler gefehlt hat. Sie gehört dir und macht dich unabhängig — auch von mir.

Was dringend ist.

1. Zugänge auf dein Unternehmen übertragen.
2. Sicherung einrichten, automatisch und getestet.
3. Akute Sicherheitslücken schließen.
4. PHP-Version auf einen unterstützten Stand bringen (PHP 7 auf 8).
5. Überwachung, damit Ausfälle auffallen.

Alles andere — Umbau, neue Funktionen, Modernisierung — kommt danach und kann geplant werden.

Wie es weitergeht.

Nach der Übernahme gibt es drei Wege: die Anwendung stabil halten und pflegen, sie schrittweise modernisieren oder sie mittelfristig ersetzen. Welcher Weg sinnvoll ist, zeigt die Bestandsaufnahme (Individuell oder Standard).

Vorbeugen.

• Zugänge immer auf das Unternehmen, nie auf den Entwickler.
• Code in einem Repository, auf das du Zugriff hast.
• Dokumentation als Teil jedes Auftrags.
• Verbreitete Grundlagen statt Eigenbau ohne Framework (Laravel).

Wenn du nicht weiterkommst.

Wenn der Entwickler deiner Anwendung nicht mehr erreichbar ist und du wieder Kontrolle brauchst. Ich sehe mir den Code an, sage dir, wo die Risiken liegen, und setze um, was nötig ist. Die Übersicht findest du unter PHP und Laravel; wenn es eilt, hilft der Notfall-Support.

Orientierungswerte, keine Fixpreise — nach einem kurzen Gespräch bekommst du ein Festpreisangebot.

Wer hilft.

Ich bin Manuel Killert, Webentwickler aus Quakenbrück. PHP ist die Sprache, in der ich seit Jahren am meisten Code schreibe — in WordPress-Plugins, Shop-Erweiterungen, Schnittstellen und eigenständigen Anwendungen mit Laravel. Ich unterrichte Webentwicklung als Dozent und kenne PHP vom alten prozeduralen Skript bis zur modernen, typisierten Anwendung mit Tests.

Gerade bei bestehenden Anwendungen zählt das: Ich lese fremden Code schnell, erkenne, wo er gegen die Sprache arbeitet, und sehe, was sich mit vertretbarem Aufwand retten lässt. Viele PHP-Projekte, die als hoffnungslos gelten, sind es nicht — sie wurden nur lange nicht gepflegt.

Was du bekommst: eine ehrliche Einschätzung, ob sich modernisieren oder neu bauen lohnt, sauberen Code, den auch andere Entwickler verstehen, und eine Dokumentation — auch wenn die Antwort lautet, dass die Anwendung so bleiben kann.