Der einzige Entwickler hat gekündigt, und kannte den Code
Die Ausgangslage
Ein Großhandelsunternehmen aus Nordrhein-Westfalen, rund 40 Mitarbeitende, betreibt seit 2013 eine eigene Auftrags- und Lagerverwaltung. PHP 7.2, MySQL 5.7, ein paar JavaScript-Schnipsel im Frontend, kein Framework, gewachsen über die Jahre. Das System funktioniert. Es ist kein Drittprodukt, sondern exakt auf die Prozesse des Unternehmens zugeschnitten: Sammelrechnungen, Kommissionierdrucke, Schnittstellen zu zwei Speditionen.
Der Entwickler, der dieses System gebaut und über 13 Jahre weitergepflegt hatte, kündigt. Nach acht Wochen Restlaufzeit ist er weg. Eine Übergabe gab es im Wochenrhythmus, dokumentiert wurde wenig. Keine README, keine Architekturskizze, keine aktuelle Liste der Cronjobs. Was es gab: ein Git-Repository, ein Backup-Script auf dem Server, und einen Geschäftsführer mit der Frage „Was machen wir jetzt?".
Nach drei Wochen ohne Entwickler tauchen die ersten Probleme auf. Ein Cronjob schreibt Logs voll. Ein Spediteur ändert sein API-Format. Eine Kundin meldet falsche Rechnungssummen. Niemand im Haus kann das selbst beheben. Die Geschäftsführung sucht externe Hilfe. Keine Agentur, die „neu bauen" will, sondern jemanden, der den bestehenden Code übernimmt.
Was wir gemacht haben
Wir haben in der ersten Woche einen System-Audit gemacht. Repository klonen, lokale Entwicklungsumgebung aufsetzen, Datenbankschema dokumentieren. Wir haben alle Cronjobs gelistet, jeden Endpoint katalogisiert und die externen Schnittstellen identifiziert. Parallel dazu haben wir mit dem Innendienst gesprochen: wer nutzt was, wann, und woran erkennt man, dass etwas kaputt ist.
In Woche zwei haben wir das Logging zentralisiert und ein Sentry-Projekt eingerichtet. Backups wurden überprüft (zwei der drei Backup-Stände waren korrupt). Die offenen Tickets (das defekte Spediteur-Format, die falsche Rechnungssumme, der vollgelaufene Log) wurden abgearbeitet. Außerdem haben wir eine schlanke Dokumentation erstellt: ein Markdown-File pro Subsystem, das beschreibt, was es tut, wo es liegt und woran man Fehler erkennt.
Wir haben den Code respektiert wie er ist. Kein „wir bauen das mal eben in Laravel neu". Keine Modernisierung um der Modernisierung willen. Das System läuft, die Prozesse passen, der Code ist lesbar. Er ist nur eben angesammelt. Diese Schulden lassen sich tilgen, aber das ist ein zweiter Schritt.
Das Ergebnis
Nach zwei Wochen lief die Wartung. Die Geschäftsführung hatte einen festen Ansprechpartner mit garantierten Reaktionszeiten. Bugs werden innerhalb von 48 Stunden bearbeitet, Sicherheitsupdates monatlich eingespielt. Die Logs werden überwacht, Fehler landen automatisch im Ticketsystem.
Sechs Monate später haben wir gemeinsam mit der Geschäftsführung einen Tilgungsplan für die technischen Schulden aufgesetzt: PHP-Upgrade auf 8.2, Migration der MySQL-Instanz, schrittweise Einführung von Tests für die Rechnungsmodule. Kein Big-Bang-Projekt, sondern saubere Sanierung über zwölf Monate, parallel zur laufenden Wartung.
Das Unternehmen hat keine Software verloren, sondern einen Entwickler. Die Software war nie das Problem.