Wenn kein Entwickler mehr da ist: Notfallplan für das Legacy-System
Der Entwickler kündigt, das Legacy-System bleibt. So beginnt eine der häufigsten Notlagen im Mittelstand. Ein Mensch hat das System über Jahre gebaut und betreut. Jetzt ist er weg. Vielleicht in Rente, vielleicht beim Wettbewerber. Und niemand im Haus weiß, wie die Software im Inneren funktioniert.
Die Software läuft trotzdem weiter. Das ist die gute Nachricht. Die schlechte: Sie läuft nur so lange, bis etwas passiert. Ein Serverwechsel, ein abgelaufenes Zertifikat, eine neue Schnittstelle des Steuerberaters. Dann steht die Frage im Raum, wer sich das anschaut.
Dieser Artikel ist ein Notfallplan. Er richtet sich an Geschäftsführer und IT-Verantwortliche, die selbst nicht programmieren. Sie brauchen dafür keinen Editor. Sie brauchen eine Reihenfolge.
Warum die Ruhe nach der Kündigung trügt
Legacy-Software ist alte Software, die noch produktiv genutzt wird. Sie ist meist stabil, weil sie seit Jahren dieselben Aufgaben erledigt. Diese Stabilität verdeckt das eigentliche Problem: Das Wissen über das System steckte im Kopf eines Menschen, nicht in Dokumenten.
Wenn dieser Mensch geht, verlieren Sie nicht den Code. Der liegt auf dem Server. Sie verlieren die Landkarte dazu. Welche Datei macht was? Warum steht dort ein Workaround aus 2014? Welches Skript läuft nachts um drei? Das weiß jetzt niemand mehr.
Ein typischer Fall: Ein Handelsunternehmen mit rund 40 Mitarbeitern. Das Warenwirtschaftssystem lief seit elf Jahren, gebaut von einem einzigen Entwickler. Nach seinem Abschied fiel drei Monate lang nichts auf. Dann verweigerte der Zahlungsdienstleister eine veraltete Schnittstelle. Der Versand stand zwei Tage still. Erst dann suchte die Geschäftsführung Hilfe.
Teuer war am Ende weniger der Stillstand als die drei ruhigen Monate davor, in denen niemand hingeschaut hat.
Was passiert, wenn Sie nichts tun
Ohne Betreuung altert Software schneller als man denkt. Sicherheitslücken bleiben offen, weil niemand Updates einspielt. Das betrifft die Programmiersprache, das Datenbanksystem und alle Bibliotheken dazwischen. Nach einem Jahr ohne Pflege ist ein System, das vorher sicher war, angreifbar.
Dazu kommen die kleinen Dinge. Ein Passwort läuft ab. Ein Cronjob, also ein zeitgesteuerter Automatismus, bricht ab. Eine Rechnung wird nicht mehr erzeugt. Jeder dieser Fälle ist einzeln harmlos. Zusammen erzeugen sie ein Gefühl von Kontrollverlust, das Ihr Team lähmt.
Und schließlich die DSGVO. Wer personenbezogene Daten verarbeitet, muss sie nach dem Stand der Technik schützen. Ein System, das seit dem Weggang des Entwicklers keine Sicherheitsupdates mehr erhalten hat, erfüllt diesen Anspruch nicht. Im Schadensfall werden Sie danach gefragt.
Der Notfallplan in vier Phasen
Die folgenden Phasen bauen aufeinander auf. Sie müssen nicht alles auf einmal erledigen. Aber Sie sollten heute mit Phase eins beginnen.
Phase 1: Stabilisieren (erste Woche)
Ziel dieser Phase ist ein System, das nicht ohne Vorwarnung ausfällt. Dafür braucht es keine Entwicklung, sondern Übersicht.
Sichern Sie zuerst alle Zugänge. Serverpasswörter, Hosting-Konto, Domain, Datenbank, Code-Repository, E-Mail-Konten der Anwendung. Prüfen Sie, ob der ausgeschiedene Entwickler noch Zugriff hat. Wenn ja, ändern Sie die Passwörter und dokumentieren Sie das neue Vorgehen. Das hat mit Misstrauen wenig zu tun. Es ist einfach Sorgfalt.
Prüfen Sie dann, ob ein Backup existiert und ob es funktioniert. Ein Backup, das noch nie zurückgespielt wurde, ist eine Hoffnung, kein Backup. Lassen Sie den Hoster oder einen externen Techniker eine Wiederherstellung auf einem Testsystem durchführen.
Erstellen Sie eine einfache Liste der Dinge, die das System täglich tut. Rechnungen, Bestellungen, Exporte, Schnittstellen zu anderen Programmen. Wer im Unternehmen merkt es zuerst, wenn etwas davon ausbleibt? Diese Person wird Ihr Frühwarnsystem.
Phase 2: Wissen sichern (Woche 2 bis 4)
Jetzt geht es darum, so viel Landkarte wie möglich zu rekonstruieren. Auch ohne Entwickler im Haus.
Falls der ehemalige Entwickler noch erreichbar ist: Bieten Sie ihm ein bezahltes Übergabe-Gespräch an. Zwei bis vier Stunden, per Video, aufgezeichnet. Stellen Sie einfache Fragen. Wo liegt der Code? Wie wird eine neue Version eingespielt? Was hat ihm in den letzten Jahren am meisten Sorgen gemacht? Die Antworten sind Gold wert, selbst wenn sie unvollständig bleiben.
Sammeln Sie danach alles, was schriftlich existiert. Alte E-Mails mit Fehlerbeschreibungen, Notizen, Tickets, Kommentare im Code. Wie so eine Sammlung aufgebaut wird, beschreibt unser Artikel zum Thema Dokumentation für Legacy-Software erstellen. Sie brauchen keine perfekte Doku. Ein Ordner mit klarer Struktur reicht für den Anfang.
Wichtig in dieser Phase: Ändern Sie nichts am Code. Jede Änderung ohne Verständnis erzeugt neue Probleme. Beobachten geht vor Eingreifen.
Phase 3: Extern übernehmen lassen (Monat 2 bis 3)
Spätestens jetzt braucht das System wieder einen Betreuer. Für die meisten Unternehmen dieser Größe ist eine Neueinstellung der falsche Weg. Ein Entwickler, der nur ein altes System pflegt, ist schwer zu finden und noch schwerer zu halten. Und Sie hätten in ein paar Jahren wieder dasselbe Problem.
Ein externer Dienstleister für Software-Wartung übernimmt das System als Ganzes. Der Ablauf beginnt mit einer Systemanalyse: Welche Sprache, welche Version, welche Abhängigkeiten, welche Risiken. Danach folgt ein Wartungsplan mit klaren Prioritäten. Sicherheitsupdates zuerst, dann Stabilität, dann Komfort.
Achten Sie bei der Auswahl auf zwei Dinge. Erstens: Der Dienstleister muss Erfahrung mit alten Stacks haben. Wer nur moderne Frameworks kennt, wird Ihnen eine Neuentwicklung empfehlen. Zweitens: Der Dienstleister muss Dokumentation als Teil der Arbeit sehen. Sonst tauschen Sie einen Wissensträger gegen den nächsten.
Wie ein solcher Übergang konkret abläuft, lesen Sie im Beitrag Outsourcing der Legacy-Wartung: der Übergang.
Phase 4: Langfristig entscheiden (ab Monat 4)
Erst wenn das System stabil und betreut ist, stellt sich die große Frage: Weiterpflegen, modernisieren oder ersetzen?
Diese Frage lässt sich nicht aus dem Bauch beantworten. Sie braucht Zahlen. Was kostet die laufende Wartung pro Jahr? Welche Funktionen fehlen dem Geschäft? Wie viele technische Schulden haben sich angesammelt, und was kostet es, sie schrittweise abzubauen?
Oft ist die Antwort überraschend unspektakulär. Ein altes System, das gut betreut wird, läuft noch viele Jahre. Eine Neuentwicklung kostet dagegen sechsstellig und bindet Ihr Team monatelang. Modernisierung in kleinen Schritten liegt meist dazwischen und lässt sich jederzeit anpassen.
Was Sie in dieser Phase auf keinen Fall tun sollten: Unter Druck entscheiden. Der Druck ist nach Phase drei weg. Nutzen Sie diese Ruhe.
Was Sie als Nicht-Techniker selbst tun können
Vieles aus diesem Plan können Sie ohne Programmierkenntnisse umsetzen. Zugänge sammeln, Backups anfordern, Prozesse auflisten, Gespräche führen. Das ist Organisationsarbeit, und die kann jede Assistenz übernehmen.
Was Sie nicht tun sollten: Selbst am Code herumprobieren oder einen Bekannten mit Halbwissen daran lassen. Ein Legacy-System hat seine Eigenheiten. Die sind über Jahre gewachsen und haben meist einen Grund. Wer sie nicht kennt, richtet mit guten Absichten Schaden an.
Falls Sie gerade erst erfahren haben, dass Ihr Entwickler geht, hilft Ihnen auch unser Artikel Wenn der letzte Legacy-Entwickler geht: was tun?. Dort geht es um die ersten Stunden nach der Kündigung.
Fazit: Die ersten Tage entscheiden
Wenn Ihr Entwickler kündigt, ist das Legacy-System nicht verloren. Es ist nur vorübergehend ohne Betreuung. Wer die erste Woche nutzt, um Zugänge, Backups und Prozesse zu sichern, gewinnt Zeit. Wer die ersten Monate nutzt, um Wissen zu sammeln und einen Betreuer zu finden, gewinnt Ruhe.
Der schlechteste Plan ist der, der auf den ersten Ausfall wartet.
Wir übernehmen Legacy-Systeme in PHP, Java und JavaScript, auch ohne Dokumentation und ohne Vorgänger. Sprechen Sie uns an. Das Erstgespräch ist kostenlos, und Sie bekommen eine ehrliche Einschätzung, wo Ihr System steht.
