Was passiert wenn der letzte Legacy-Entwickler das Unternehmen verlässt?

"Entwickler gekündigt, Software läuft noch" - und jetzt? Ein häufiges und unterschätztes Szenario im Mittelstand. Der einzige Entwickler, der das System wirklich kennt, verlässt das Unternehmen. Keine Dokumentation. Kein Einarbeitungsplan. Kein Nachfolger in Sicht.

Was dann passiert, läuft nach einem vertrauten Muster ab. Zunächst läuft alles weiter. Dann kommt der erste Fehler. Und plötzlich steht die Frage: Wer weiß überhaupt noch, wie das funktioniert?

Dieser Artikel erklärt, was Sie in diesem Moment tun können. Und wie Sie künftig verhindern, in dieselbe Lage zu kommen.

Das unterschätzte Risiko: Wissen das mitgeht

Manchmal ist das wertvollste Asset an einem Softwaresystem nicht der Code. Es ist das Wissen darüber.

Wer kennt die undokumentierten Eigenheiten? Wer weiß, warum bestimmte Dinge so gebaut wurden, wie sie sind? Wer kennt den Workaround für das Problem das alle sechs Monate auftaucht?

Dieses Wissen steckt im Kopf des Entwicklers. Nicht im System. Wenn dieser Mensch geht, geht das Wissen mit.

Legacy Software hat dieses Problem besonders ausgeprägt. Alte Systeme sind selten vollständig dokumentiert. Entscheidungen aus 2008 sind längst nicht mehr nachvollziehbar. Kommentare im Code fehlen oft. Oder sie beschreiben das Was, nicht das Warum.

Das ist kein Versagen. Das ist der normale Zustand einer Software, die über Jahre gewachsen ist.

Was passiert in den ersten Wochen nach dem Abgang?

Am Anfang läuft alles normal. Die Software tut, was sie soll. Das Team atmet auf.

Dann passiert etwas. Ein Fehler taucht auf. Eine kleine Änderung wird nötig. Oder ein Server verhält sich seltsam.

Und dann stellt sich heraus, dass niemand wirklich weiß, wie das System zusammenhängt.

Das ist kein theoretisches Risiko. Es ist eine vorhersehbare Abfolge. Die ersten Probleme sind oft klein. Aber ohne das nötige Wissen kosten kleine Probleme plötzlich viel Zeit.

Externe Entwickler, die einspringen sollen, brauchen Wochen um sich einzuarbeiten. Manchmal Monate. Und während der Einarbeitungszeit läuft das System weiter - ohne jemanden, der es wirklich versteht.

Viele Unternehmen wundern sich, warum ein einfacher Bugfix drei Wochen dauert. Der Grund liegt fast immer im fehlenden Wissen über das System, nicht an der Komplexität des Fehlers selbst.

Was Sie sofort tun können

Der beste Zeitpunkt für Vorbereitung ist, bevor jemand kündigt. Aber der zweitbeste Zeitpunkt ist jetzt - auch wenn die Kündigung schon eingegangen ist.

Wissenstransfer fordern, noch vor dem letzten Tag

Wenn der Entwickler noch im Haus ist: Nutzen Sie diese Zeit aktiv.

Setzen Sie einen strukturierten Wissenstransfer an. Kein informelles "Kurz mal erklären". Sondern geplante Termine mit klaren Themen.

Was soll übergeben werden? Systemarchitektur, Deployment-Prozess, bekannte Fehlerquellen, externe Abhängigkeiten und Zugänge. Das klingt nach viel. Es ist machbar, wenn man es früh angeht.

Bitten Sie den Entwickler, einen "Notfallzettel" zu schreiben. Was soll jemand wissen, wenn um drei Uhr nachts etwas nicht mehr funktioniert? Zehn konkrete Sätze sind wertvoller als hundert Seiten Handbuch, die niemand liest.

Das System von außen analysieren lassen

Manchmal weiß auch der scheidende Entwickler nicht alles. Oder er kann es nicht gut erklären. In diesem Fall hilft ein externer Blick.

Ein erfahrener Spezialist für Legacy Software kann ein System analysieren, ohne dass jemand es erklärt. Er kennt die üblichen Muster. Er weiß, wo man nachschauen muss.

Das Ergebnis ist eine Bestandsaufnahme. Kein akademisches Dokument, sondern eine ehrliche Antwort auf die Frage: Was haben wir hier eigentlich?

Diese Bestandsaufnahme ist der Ausgangspunkt für alles Weitere. Für eine Übergabe. Für eine Wartungsvereinbarung. Oder für eine spätere Modernisierung.

Externe Wartung als Übergangslösung einplanen

In der Zeit zwischen dem Abgang des Entwicklers und einer Neuregelung braucht das System Betreuung. Keine dauerhafte Lösung, aber ein verlässliches Netz.

Externe Software-Wartung übernimmt genau das. Reaktionsbereitschaft, Monitoring, und die Kapazität einzuspringen, wenn etwas passiert.

Das gibt Zeit, um in Ruhe eine langfristige Lösung zu planen. Ohne das System in dieser Zeit unbeaufsichtigt zu lassen.

Wie Sie sich künftig absichern

Das Szenario "Entwickler gekündigt, Software läuft noch - was jetzt?" lässt sich nicht immer verhindern. Aber man kann dafür sorgen, dass es kein Notfall wird.

Dokumentation ist kein Luxus

Jede Änderung am System sollte kurz festgehalten werden. Nicht für die Nachwelt. Für den nächsten Entwickler. Oder für Sie selbst in zwei Jahren.

Kurze Beschreibungen, was geändert wurde und warum, reichen oft aus. Wichtig ist die Kontinuität. Dokumentation die einmal gemacht und nie gepflegt wird, ist nach einem Jahr wertlos.

Fragen Sie Ihren Entwickler beim nächsten Gespräch: Wo ist das erklärt? Wenn die Antwort "nirgends" oder "in meinem Kopf" lautet, ist das ein Signal.

Wissensilos auflösen

Wenn nur eine Person weiß, wie ein kritisches System funktioniert, ist das ein strukturelles Risiko. Genauso wie ein einzelner Zugangscode, der nur einem Mitarbeiter bekannt ist.

Sorgen Sie dafür, dass mehrere Menschen grundlegendes Wissen über Ihre Software haben. Das muss kein technisches Tiefenwissen sein. Aber jemand sollte wissen: Wie wird das System gestartet? Wo liegen bekannte Schwachstellen? Wen ruft man an, wenn nachts etwas passiert?

Wartungsvertrag als strukturierte Absicherung

Wer keine interne IT hat, braucht einen verlässlichen externen Partner. Nicht als Feuerwehr, die nur bei Bränden anrückt, sondern als kontinuierliche Betreuung.

Ein guter Wartungsvertrag enthält klare Reaktionszeiten, definierte Verantwortlichkeiten und die Bereitschaft, sich mit dem System wirklich auseinanderzusetzen. Auch wenn es alt ist. Auch wenn der Code nicht schön aussieht.

Denn technische Schulden verschwinden nicht, wenn man sie ignoriert. Sie wachsen.

Was über dieses Szenario hinaus zählt

Der Abgang eines einzelnen Entwicklers ist oft das erste Mal, dass ein Unternehmen realisiert, wie abhängig es von implizitem Wissen ist.

Wer jetzt handelt, hat die Kontrolle über den Prozess. Wer wartet, bis das nächste Problem auftaucht, hat sie nicht mehr.

Das gilt auch für den Fall, dass noch kein Entwickler gekündigt hat. Fragen Sie sich: Wenn morgen die Person geht, die Ihre Software am besten kennt, wie lange wäre Ihr Betrieb handlungsfähig? Ein Tag? Eine Woche? Gar nicht?

Die Antwort zeigt Ihnen, wie dringend das Thema ist.

Fazit: Handeln bevor die Stille endet

Software läuft meistens. Bis sie es nicht mehr tut. Und dann zählt nicht, was die Software kann, sondern wer sie noch versteht.

Sprechen Sie uns an. Wir schauen uns Ihr System an und sagen Ihnen ehrlich, wo Sie stehen. Das Erstgespräch ist kostenlos.