Der Entwickler ist weg: Wie es mit der Anwendung weitergeht

Wenn die Person geht, die die Anwendung gebaut hat, ist das erste Problem nicht der Code. Es ist die Frage, wer Server, Domains und Zugänge kontrolliert. Danach folgen Wochen, in denen niemand genau weiß, welche Teile des Systems geschäftskritisch sind.

Die ersten 30 Tage entscheiden, ob der Betrieb weiterläuft. Dieser Text beschreibt die Reihenfolge, in der die wichtigsten Aufgaben sinnvoll sind.

Zuerst Zugänge und Kontrolle sichern

Beginnen Sie mit einer Liste aller Zugänge. Dazu gehören Server und Root-Zugriff, Hosting- oder Cloud-Konsole, Domain-Registrar, DNS, administrative E-Mail-Konten, CI/CD, Git-Remote, Paket-Registries, Monitoring, Backup-Speicher, Datenbankzugänge und Dashboards von Drittanbietern wie Zahlungsanbietern.

Prüfen Sie, welche Konten an die Privatadresse der Person gebunden sind. Ein Passwort-Reset für ein Konto, dessen Inhaber nicht erreichbar ist, kann Wochen dauern und ist bei Domains ein echtes Risiko. Übertragen Sie solche Konten auf Unternehmensadressen und aktivieren Sie Zwei-Faktor-Authentifizierung.

Entfernen Sie keinen Zugang, bevor ein Ersatzzugang nachweislich funktioniert. Sperren Sie erst, wenn die neue Person sich anmelden und die wichtigsten Aufgaben ausführen konnte.

Arbeiten Sie mit einem Passwortmanager, in dem jedes Konto einen eigenen Eintrag hat. Prüfen Sie zusätzlich SSH-Schlüssel und API-Schlüssel: Wer besitzt sie, wo liegen sie, und welche Systeme akzeptieren sie noch?

Ein System, dessen Zugänge niemandem im Unternehmen gehören, ist nicht im Besitz des Unternehmens.

Ein vollständiges Backup und ein bewiesener Restore

Erstellen Sie ein Backup von Dateien, Datenbank, Konfiguration, Secrets und Zertifikaten. Behandeln Sie es als ungeprüft, bis eine Wiederherstellung tatsächlich funktioniert hat.

Setzen Sie die Anwendung in einer isolierten Umgebung aus dem Backup wieder auf. Messen Sie, wie lange das dauert. Legen Sie das Ergebnis an einen Ort, der nicht vom ausgefallenen System abhängt, und notieren Sie jeden Schritt, den Sie dabei ausführen. Diese Notizen sind der Anfang Ihrer Betriebsdokumentation, und sie entstehen zu einem Zeitpunkt, an dem das System noch läuft.

Prüfen Sie zusätzlich, ob die laufenden Backups wirklich vollständig sind. Ein grüner Backup-Job sagt nichts darüber aus, ob die Datenbank enthalten ist oder ob der Schlüssel zur Entschlüsselung auffindbar ist.

Das Systembild aufbauen

Sammeln Sie, was das System ausmacht: Repository und Branch-Struktur, Deployment-Skripte, Webserver-Konfiguration, Cronjobs, systemd-Units, laufende Prozesse, offene Ports, Queue-Worker, geplante Aufgaben, externe Integrationen und DNS-Einträge.

Lokale Änderungen auf dem Server sind ein häufiger Fund. Suchen Sie nach Dateien, die nicht im Repository stehen, und nach Diensten, die niemand kennt. Ein Vergleich zwischen Repository und Server zeigt schnell, wo der tatsächliche Stand liegt.

Das Ergebnis muss kein vollständiges Architekturdokument sein. Eine Übersicht mit Komponenten, Datenflüssen und externen Abhängigkeiten reicht, damit eine Änderung nicht blind erfolgt. Notieren Sie offene Fragen genauso wie Antworten. Ein Bereich, den niemand erklären kann, ist selbst ein Befund und gehört auf die Risikoliste.

Kritische Abhängigkeiten finden und einfrieren

Listen Sie auf, was außerhalb des eigenen Servers liegt: Zahlungsanbieter, E-Mail- und SMS-Versand, Karten, Steuerdienste, ERP-Schnittstellen, kommerzielle PHP-Pakete, Lizenzen, Themes und Fonts. Notieren Sie Fristen und Vertragsverantwortliche.

Domain-Namen und TLS-Zertifikate gehören ganz nach oben. Ein abgelaufenes Zertifikat legt die Anwendung lahm, und ein abgelaufener Domainname gefährdet mehr als nur die Erreichbarkeit. Prüfen Sie außerdem, ob Rechnungen für Drittanbieter an eine Adresse gehen, die niemand mehr liest.

Auch kleine Dienste zählen. Ein Cronjob, der Rechnungen über die API eines Anbieters versendet, dessen Konto auf eine Privatadresse läuft, wird zum Ausfall, sobald das Konto gesperrt wird.

Bis das System verstanden ist, gilt ein Einfrieren: keine Framework-Updates, keine neuen Funktionen, keine Serverwechsel, außer es ist für den Betrieb notwendig. Diese Regel schützt vor Veränderungen, deren Auswirkungen niemand einschätzen kann. Sicherheitsupdates brauchen eine Ausnahme, aber mit Test und Rückfallweg.

Nach Geschäftswert priorisieren

Nicht alles ist gleich wichtig. Listen Sie die Abläufe, die Geld oder Kundenbeziehungen betreffen: Anmeldung, Checkout, Zahlungs-Callbacks, Rechnungserstellung, Exporte, Kundenportal und administrative Freigaben. Diese bekommen zuerst Aufmerksamkeit.

Ein kleines Sicherheitsnetz reicht für den Anfang: eine Erreichbarkeitsprüfung, Fehleralarme per E-Mail, ein zentrales Log und ein dokumentierter Weg, die Anwendung neu zu starten. Ein Runbook für den häufigsten Ausfall ist mehr wert als ein umfangreiches Monitoring-Konzept, das noch nicht existiert.

Prüfen Sie für jeden kritischen Ablauf, ob er heute getestet ist. Wo kein Test existiert, ist ein manueller Durchlauf vor der ersten Änderung sinnvoll.

Kosmetische Themen, veraltete Gestaltung oder unaufgeräumte Daten warten. Sie kosten Zeit, lösen aber kein Betriebsrisiko. Die Frage ist nicht, ob ein Fehler auftreten kann, sondern was er kostet. Ein Checkout, der zwei Stunden ausfällt, ist ein anderes Problem als ein falsch sortierter Export am Monatsende.

Ehrlich mit Stakeholdern kommunizieren

Vermeiden Sie Optimismus, der in zwei Wochen widerlegt wird. Berichten Sie, was gesichert ist, was noch offen ist und wo Risiken liegen. Zugänge, Backup, Systembild und Abhängigkeiten sind konkrete Punkte, die sich mit Status versehen lassen.

Benennen Sie Entscheidungen statt nur Probleme. Etwa: Bis wann übernimmt eine feste Person den Betrieb? Wann fällt die Entscheidung über Modernisierung oder Ablösung? Welche Funktionen sind verzichtbar, falls die Anwendung ausfällt?

Führen Sie eine einfache Risikoliste mit vier Spalten: Punkt, Status, Verantwortliche, Frist. Dieses Dokument ersetzt lange Statusberichte und hält die wichtigsten Entscheidungen sichtbar.

Diese Kommunikation ist kein Eingeständnis von Schwäche. Sie ist die Grundlage dafür, dass das Unternehmen eine informierte Entscheidung trifft, statt auf die nächste Überraschung zu warten.

Fazit

Die ersten 30 Tage entscheiden nicht, wie modern die Anwendung ist. Sie entscheiden, ob der Betrieb kontrolliert wird. Der Maßstab ist nicht Vollständigkeit, sondern Kontrolle über die Systeme, von denen der Betrieb abhängt. Zugänge, ein bewiesener Restore, ein Systembild und ein klarer Blick auf die Abhängigkeiten schaffen die Basis für alles Weitere.

Wenn die Anwendung übernommen und stabilisiert werden soll, beginnt das mit Code-Rettung. Für den laufenden Betrieb und die schrittweise Verbesserung ist Application Management der passende Rahmen. Der Beitrag Übernahme ohne Dokumentation beschreibt, wie Sie sich fehlendes Wissen systematisch erarbeiten, und technische Schulden erkennen zeigt, welche Risiken danach zuerst anzugehen sind.