Der Programmierer ist weg. Ihre Software muss bleiben.

Beginnen Sie mit einer einfachen Bestandsliste. Wo läuft die Anwendung? Wer hat die Konten angelegt? Wer bezahlt den Server, die Domain oder angeschlossene Dienste? Gibt es einen Zugang zum Quellcode? Liegen Verträge, Rechnungen oder frühere Übergabeunterlagen vor?

Ihr Unternehmen muss über die benötigten Zugänge selbst verfügen können. Hängt ein Konto nur an der privaten E-Mail-Adresse des früheren Entwicklers, kann das später zum Hindernis werden. Übertragen oder sichern Sie Zugänge kontrolliert. Ändern Sie nicht wahllos Passwörter, solange Sie die Abhängigkeiten nicht kennen.

Klären Sie auch die Nutzungsrechte. Eine Anwendung wird nicht „rechtefrei“, weil ihr Entwickler verschwunden ist. Was geändert werden darf und ob ein Anspruch auf Quellcode besteht, hängt unter anderem von Verträgen und den gesetzlichen Voraussetzungen ab. Ist das unklar, gehört eine juristische Prüfung dazu.

Ein Ordner namens „Backup“ beantwortet die Frage noch nicht. Sie müssen wissen, was tatsächlich gesichert wird. Nur Dateien oder auch die Datenbank, die Konfiguration und alles, was zum Starten gebraucht wird? Und kommen Sie an diese Sicherungen heran, wenn der bisherige Server nicht mehr erreichbar ist?

Probieren Sie die Wiederherstellung in einer getrennten Umgebung aus, damit der laufende Betrieb nicht gefährdet wird. Dabei merken Sie, ob Daten fehlen, Passwörter unbekannt sind oder wichtige Teile nur auf einem alten Rechner liegen. Das finden Sie lieber vor einer Änderung heraus als danach.

Planen Sie die erste größere Änderung erst, wenn es eine nachvollziehbare Sicherung und einen Weg zurück gibt. Je kritischer die Anwendung für Ihren Betrieb ist, desto sorgfältiger vereinbaren Sie Abnahme, Zeitpunkt und Ausweichverfahren.

Technisch ist zu klären, welche Komponenten beteiligt sind, wie die Anwendung bereitgestellt wird und welche Updates fehlen. Lässt sie sich aus dem vorhandenen Quellcode erstellen? Welche anderen Systeme ruft sie auf? Welche Aufgaben laufen automatisch im Hintergrund?

Genauso wichtig ist die fachliche Seite. Fragen Sie die Leute, die jeden Tag damit arbeiten. Was darf auf keinen Fall ausfallen? Welche Abkürzungen haben sie sich angewöhnt? Welche Daten pflegen sie außerhalb der Anwendung nach? An solchen unscheinbaren Details hängt oft, ob eine Änderung im Alltag funktioniert.

Das BSI beschreibt Software als Lebenszyklus mit Tests, Betrieb, Updates und späterer Außerbetriebnahme. Wer eine Anwendung übernimmt, übernimmt auch diesen Betrieb. Den Code zu öffnen und ein paar Stellen zu verstehen, reicht dafür nicht.

Weiterbetreiben und absichern kann sinnvoll sein, wenn die Anwendung fachlich passt und sich die technische Grundlage noch pflegen lässt. Dann stehen eher Dokumentation, Updates, Sicherungen und Überwachung im Vordergrund. Neue Bildschirme braucht nicht jeder Betrieb sofort.

Schrittweise modernisieren bietet sich an, wenn bestimmte Teile Probleme machen, der Kern aber trägt. Dann ersetzt man zum Beispiel einen veralteten Anschluss an die Buchhaltung, und die gewohnten Arbeitsabläufe bleiben erhalten. Geändert wird nur dort, wo es einen nachvollziehbaren Grund gibt.

Ersetzen kommt in Frage, wenn zentrale Abhängigkeiten nicht mehr tragfähig sind, wichtige Anforderungen grundsätzlich fehlen oder der Weiterbetrieb unverhältnismäßige Risiken mit sich bringt. Auch dann brauchen Sie eine Migration, denn die Daten und das Wissen über den bisherigen Betrieb verschwinden nicht mit dem alten Programm.

Für einen kontrollierten Übergang brauchen Sie eine Testumgebung, klare Prüffälle und eine fachliche Abnahme. Vergleichen Sie die wichtigen Ergebnisse. Sind die Aufträge vollständig? Stimmen die Summen? Funktionieren die Verbindungen zu anderen Programmen? Dass die Startseite erscheint, reicht nicht.

Zum eigentlichen Wechsel gehören ein vereinbarter Zeitpunkt, Zuständigkeiten und ein Rückfallplan. Ihr Team muss wissen, wen es bei Problemen anspricht und welche Einschränkungen während des Übergangs zu erwarten sind. Ist die Verantwortung unklar, kostet das bei einer Störung Zeit.

Eine Zusage wie „Das übernehmen wir in zwei Tagen“ ist ohne Bestandsaufnahme nicht seriös. Aufwand und Risiko hängen davon ab, wie gut das System dokumentiert ist, wie viele Abhängigkeiten bestehen und wie kritisch die Anwendung für Ihren Betrieb ist.

Nach der Übernahme sollte Ihr Betrieb an die wichtigen Unterlagen herankommen: den Quellcode, soweit vereinbart, die technische Dokumentation, geschützte Zugänge, Informationen zur Bereitstellung und einen Plan für Sicherung und Wiederherstellung. Dick muss die Dokumentation nicht sein, aber im Ernstfall muss sie helfen.

Legen Sie auch fest, wer Updates prüft, Störungen beobachtet und Änderungen freigibt. Wenn Sie jemanden mit der Betreuung beauftragen, sollten Umfang und Reaktionszeiten ausdrücklich festgelegt sein. „Wir kümmern uns“ klingt freundlicher als ein Vertrag, ist aber viel weniger eindeutig.

Wird der frühere Entwickler nur durch die nächste unersetzliche Person ausgetauscht, ist nichts gewonnen. Ihr Betrieb soll verstehen, was er hat, an die wichtigen Informationen kommen und auch später wieder geordnet wechseln können.