Der Anruf klingt immer ähnlich. „Unser Warenwirtschaftssystem hat ein Entwickler gebaut, der ist seit März in Rente. Es läuft. Aber jetzt brauchen wir eine kleine Änderung und wissen nicht mal, wo der Code liegt.“ Manchmal ist es keine Rente, sondern eine Agentur, die Insolvenz angemeldet hat, oder ein Freelancer, der seit drei Monaten nicht mehr auf E-Mails antwortet.
Das Unangenehme an dieser Situation: Sie fühlt sich nicht dringend an. Das System läuft ja. Deshalb wird sie aufgeschoben, bis ein Hoster eine Frist setzt, ein Kunde eine Schnittstelle braucht oder ein Server ausfällt. Dann ist sie dringend, und dann ist sie teuer.
Was Sie in den ersten 48 Stunden sichern
Bevor irgendjemand über Modernisierung redet, geht es um Besitz. Ein System, dessen Zugänge Sie nicht kontrollieren, gehört Ihnen nur auf dem Papier.
- Zugänge inventarisieren und wechseln. Hosting-Panel, SSH, Datenbank, Domain-Registrar, DNS, E-Mail-Postfächer, die die Anwendung nutzt, API-Schlüssel bei Zahlungsanbieter, Versand, Newsletter. Wer die Passwörter nicht hat, lässt sie über den jeweiligen Anbieter zurücksetzen. Der Registrar ist der wichtigste Posten: Wer die Domain kontrolliert, kontrolliert das Geschäft.
- Ein vollständiges Backup ziehen und woanders ablegen. Dateien und Datenbank, nicht nur das, was der Hoster automatisch macht. Prüfen Sie, ob das Backup sich zurückspielen lässt, sonst ist es keins.
- Aufschreiben, was läuft. Welche Domains, welche Cronjobs, welche Schnittstellen zu anderen Systemen, welche E-Mails die Anwendung verschickt. Fragen Sie die Anwender, die wissen mehr als jede Doku.
- Lizenzen und Verträge sichten. Gehört Ihnen der Quellcode laut Vertrag? Bei Agenturen ist das nicht selbstverständlich. Gibt es Lizenzen für Bibliotheken oder Verschlüsselung, die an den alten Entwickler gebunden sind?
Das können Sie selbst machen. Wenn Sie es nicht selbst machen wollen, ist es der erste halbe Tag des Befunds.
Was passiert, wenn Sie nichts tun
Das System läuft weiter, bis es das nicht mehr tut. Der Auslöser ist erfahrungsgemäß einer von vier: Der Hoster stellt die PHP-Version ab, ein Zahlungsanbieter schaltet seine alte API ab, ein Zertifikat läuft ab, oder die Festplatte ist voll, weil ein Log niemand rotiert. In allen vier Fällen steht dann jemand vor einem System, das er nicht kennt, ohne Doku, unter Zeitdruck. Das ist die teuerste Konstellation, die es in meinem Beruf gibt, und sie kostet nicht nur Geld, sondern Tage Ausfall.
Die drei realistischen Optionen
Option A: Einen Freelancer für die aktuelle Änderung holen
Jemand von einer Plattform, der die eine Änderung macht. Günstig, schnell, erledigt.
Woran es scheitert: Sie haben danach dasselbe Problem mit einem weiteren Namen im Adressbuch. Der Freelancer hat nichts dokumentiert, weil das nicht beauftragt war, und beim nächsten Mal ist er ausgelastet. Für eine einmalige, kleine Änderung ist Option A richtig. Für ein System, von dem Ihr Geschäft abhängt, verschiebt sie das Problem um ein Quartal.
Option B: Agentur beauftragen, neu bauen
Die Agentur schaut sich das Alte kurz an, empfiehlt einen Neubau, und nennt sechs bis zwölf Monate.
Woran es scheitert: Niemand weiß, was das alte System alles tut. Die Spezifikation für den Neubau wird aus dem Gedächtnis der Anwender geschrieben, und die Sonderfälle, „damals wegen des einen Kunden“, fehlen. Sie tauchen nach dem Go-live als Fehler auf, während beide Systeme parallel laufen. Manchmal ist ein Neubau richtig. Aber ohne Befund des Alten ist er eine Wette, und die Agentur trägt das Risiko nicht.
Option C: Geordnete Übernahme
Zugänge und Backup sichern, dann Befund: Ich lese Code, Datenbank und Betrieb und schreibe auf, was das System tut, wo es brennt und was es kostet, es zu behalten. Danach entweder Werkstatt-Bereitschaft, wenn das System solide ist und nur einen Ansprechpartner braucht, oder eine Modernisierung in Etappen, wenn es Substanzprobleme hat.
Woran es scheitert: Daran, dass der Befund die falsche Antwort liefern könnte. Manchmal steht darin, dass das System nicht zu halten ist. Dann haben Sie einen Festpreis für ein Dokument bezahlt, das Ihnen eine teure Fehlentscheidung erspart hat. Ich halte das für den besten Fall von Scheitern, den es gibt.
Die Reihenfolge, die ich empfehle
- Heute: die 48-Stunden-Liste oben. Zugänge, Backup, Inventar, Verträge.
- Diese Woche: Befund. Zwei bis drei Werktage lesender Zugriff. Sie bekommen ein Dokument mit Systembeschreibung, Risiko-Karte (was ist akut, was kann warten), Abhängigkeiten, und dem Aufwandsband für Minimal-Migration und Vollmodernisierung. Dazu 60 Minuten Durchsprache.
- Sofortmaßnahmen, wenn nötig. Manche Befunde haben eine rote Seite: Passwörter im Quellcode, offene Admin-URLs, kein funktionierendes Backup. Das schließe ich vor allem anderen, in Tagen, nicht Wochen.
- Betreuung oder Modernisierung. Werkstatt-Bereitschaft für ein System, das läuft und einen Ansprechpartner braucht. Vollmodernisierung in Etappen für ein System, das seine nächsten zehn Jahre verdienen soll. Beides mit Festpreis, beides ohne Big Bang.
Was ich anders mache als der Entwickler vorher
Ich dokumentiere für den Fall, dass ich selbst ausfalle. Git, ein README, das ein Fremder versteht, eine Docker-Umgebung, die den Betrieb nachstellt, ein Änderungsprotokoll. Das ist keine Geste, das ist die einzige Versicherung gegen die Situation, in der Sie gerade stecken. Sie sollen mich anrufen, weil Sie wollen, nicht weil Sie müssen.
Für wen dieser Weg nicht passt
Wenn das System eine Webvisitenkarte mit Kontaktformular ist, brauchen Sie keinen Befund, sondern einen Freelancer für einen Nachmittag. Wenn Sie ohnehin nächstes Jahr auf eine Standardsoftware wechseln und das Alte nur bis dahin durchhalten muss, reicht oft die Werkstatt-Bereitschaft ohne alles andere. Beides sage ich Ihnen im kostenlosen Kurz-Check, bevor Sie etwas beauftragen.
