Entwickler weg, Code da: So übernehmen Sie ein Projekt
Ist der bisherige Entwickler nicht erreichbar, holen Sie zuerst Domain, DNS, Server und Code-Repository auf Konten Ihres Unternehmens; danach nimmt ein neuer Dienstleister den Code auf. Geändert wird erst, wenn eine unveränderte Version über den neuen Weg live gegangen ist.
Der Anruf bleibt unbeantwortet, die Mails kommen zurück, und auf der Website erscheint seit dem Morgen eine Fehlerseite. Solche Lagen entstehen durch Krankheit, eine Insolvenz, einen Streit oder schlicht dadurch, dass ein freier Entwickler andere Aufträge angenommen hat. Für Sie zählt in diesem Moment eine Frage: Wer kann an Ihre Anwendung, wenn die eine Person ausfällt, die sie gebaut hat?
Bevor jemand Code liest, geht es um Besitz. Zugänge, die auf das Konto des bisherigen Entwicklers laufen, holen Sie in einer festen Reihenfolge zu sich, weil jeder Schritt den nächsten erst möglich macht. Wie Sie dieses Risiko im Vorfeld senken, steht unter Bus-Faktor: Was passiert, wenn Ihr einziger Entwickler ausfällt?. Die geplante Übergabe am Ende eines Projekts, bei der beide Seiten noch miteinander sprechen, ist ein anderer Fall.
Erste Tage
Sofort sichern: Zugänge, Domains, Server, Code
Die Reihenfolge folgt einer Regel: Wer die Domain hat, kontrolliert Website und E-Mail; wer den Server hat, kontrolliert die Daten; wer das Repository hat, kontrolliert den Code. Geheimnisse wie Passwörter und Schlüssel kommen zuletzt, weil Sie erst wissen müssen, wo sie überall eingetragen sind.
Domain und Registrar: Klären Sie, wer als Domaininhaber eingetragen ist und bei welchem Anbieter die Domain liegt. Bei .de-Domains hilft DENIC, wenn der bisherige Anbieter nicht mitwirkt: Der neue Provider beantragt die AuthInfo direkt bei DENIC, und DENIC schickt sie per Einschreiben an die Adresse in den Domain-Daten. Der Code verfällt nach 30 Tagen. Stimmt die hinterlegte Adresse nicht, kommt der Brief nicht an.
DNS: Stellen Sie fest, wo die DNS-Zone verwaltet wird, beim Registrar oder bei einem eigenen Dienst. Sichern Sie alle Einträge als Liste, bevor jemand etwas umstellt. Fehlt nach einem Umzug der MX-Eintrag, kommen keine E-Mails mehr an; fehlt der SPF-Eintrag, landen ausgehende Mails eher im Spam.
Hosting und Root-Zugriff: Läuft der Vertrag mit dem Hoster auf Ihr Unternehmen, setzen Sie den Root-Zugriff über dessen Kundenkonto zurück und hinterlegen einen eigenen SSH-Schlüssel. Läuft er auf den Entwickler, bitten Sie den Hoster schriftlich um eine Vertragsübernahme.
Code-Repository: Ein Repository auf GitHub kann nur übertragen, wer Administratorrechte daran hat. Laut GitHub wandern Issues, Pull Requests und Wiki mit, und auch Secrets, Deploy-Keys und Webhooks bleiben am übertragenen Repository hängen. Diese Zugänge kennt der bisherige Entwickler weiterhin.
Backups: Fragen Sie den Hoster, welche Sicherungen es gibt und von wann die letzte stammt. Ziehen Sie eine Kopie von Datenbank und hochgeladenen Dateien auf einen Speicher, der Ihnen gehört.
Drittanbieter-Konten: Mailversand, Zahlungsanbieter, App-Stores, Karten- oder Übersetzungsdienste. Wer dort als Inhaber steht, sehen Sie an den Rechnungen.
Lizenzen: CMS-Lizenzen wie Statamic Pro, kostenpflichtige Pakete, Schriften und Bilder. Prüfen Sie, auf welchen Namen sie laufen und wann sie verlängert werden müssen.
Geheimnisse: Datenbank-Passwörter, API-Schlüssel und Tokens werden erneuert, sobald Sie Repository und Server in der Hand haben. Die OWASP-Leitlinien zum Umgang mit Geheimnissen sehen vor, dass nicht mehr benötigte oder möglicherweise offengelegte Geheimnisse widerrufen werden. Wer zu früh tauscht, ohne die Stellen zu kennen, an denen ein Schlüssel eingetragen ist, legt die Anwendung selbst lahm.
Heikler ist der Fall, dass der Entwickler selbst als Domaininhaber eingetragen ist. Dann führt der Weg über die AuthInfo nicht weiter, denn der Brief geht an ihn. Sie brauchen seine Zustimmung zum Inhaberwechsel oder müssen die Herausgabe der Domain verlangen. Damit die Domain in der Zwischenzeit nicht an Dritte geht, gibt es bei .de-Domains den DISPUTE-Eintrag der DENIC: Wer ein Namens- oder Kennzeichenrecht nachweist und es gegenüber dem Inhaber geltend macht, sperrt damit die Übertragung an Dritte, zunächst für ein Jahr; wird die Domain gelöscht, geht sie an den Inhaber des Eintrags.
Ob Sie den Code nutzen und ändern dürfen, regelt der Vertrag mit dem bisherigen Entwickler; das Urheberrecht an Computerprogrammen steht in §§ 69a ff. UrhG. Legen Sie den Vertrag neben die Liste, die im nächsten Abschnitt entsteht. Fehlt eine klare Regel zu Nutzungsrechten oder zur Domain, lassen Sie das im Einzelfall rechtlich prüfen, bevor der neue Dienstleister den Code ändert.
Bestandsaufnahme
Bestandsaufnahme ohne Panik
Mit der Liste aus Schritt 1 bis 8 entsteht ein Inventar: Was gibt es, wo liegt es, wer hat Zugriff, und ist es schon gesichert? Füllen Sie es zuerst aus Rechnungen, Verträgen und alten Mails, bevor der neue Dienstleister beginnt. Jede Zeile, die Sie selbst klären, muss niemand gegen Bezahlung suchen.
Lassen Sie unbekannte Felder offen. Eine Zeile „Wo läuft der nächtliche Datenabgleich? unbekannt“ ist für den neuen Dienstleister wertvoller als eine geschätzte Antwort.
Kopieren Sie die Vorlage in eine Datei Ihres Unternehmens, nicht in ein Konto des neuen Dienstleisters.
# Inventar Softwareprojekt
Stand: TT.MM.JJJJ | ausgefüllt von: ...
## 1. Domain und Registrar
| Domain | Domaininhaber | Registrar | Login bei uns? | Verlängerung am | gesichert? |
|--------|---------------|-----------|----------------|-----------------|------------|
| ... | ... | ... | ja / nein | ... | ja / nein |
## 2. DNS
| Zone verwaltet bei | Einträge exportiert am | MX / SPF / DKIM vorhanden? |
|--------------------|------------------------|----------------------------|
| ... | ... | ... |
## 3. Hosting und Server
| Server / Dienst | Anbieter | Vertragspartner | Root/SSH für uns? | Betriebssystem, Version |
|-----------------|----------|-----------------|-------------------|-------------------------|
| ... | ... | ... | ja / nein | ... |
## 4. Code
| Repository | Plattform | Eigentümer | Admin bei uns? | letzter Commit am | Deployment-Weg |
|------------|-----------|------------|----------------|-------------------|----------------|
| ... | ... | ... | ja / nein | ... | manuell / Pipeline / unbekannt |
## 5. Backups
| Was | Wo | Takt | letzte Sicherung | Kopie bei uns? | Wiederherstellung geprobt? |
|-----|----|------|------------------|----------------|----------------------------|
| Datenbank | ... | ... | ... | ja / nein | ja / nein |
| Dateien | ... | ... | ... | ja / nein | ja / nein |
## 6. Drittanbieter
| Dienst | Zweck | Konto läuft auf | Rechnung an | Zugang bei uns? |
|--------|-------|-----------------|-------------|-----------------|
| ... | ... | ... | ... | ja / nein |
## 7. Lizenzen
| Produkt | Lizenznehmer | Ablauf / Verlängerung | Schlüssel abgelegt in |
|---------|--------------|-----------------------|-----------------------|
| ... | ... | ... | ... |
## 8. Geheimnisse (nur Ablageort, nie den Wert eintragen)
| Geheimnis | eingetragen in | erneuert am | erneuert von |
|-----------|----------------|-------------|--------------|
| ... | ... | ... | ... |
## Offene Fragen
- ...
Neuer Dienstleister
Einarbeitung realistisch planen
Die Einarbeitung in fremden Code beginnt mit vier Fragen: Lässt sich die Anwendung lokal starten? Lässt sich eine Version ausliefern? Welche Abläufe tragen das Geschäft? Und wie alt sind Framework, PHP und Pakete? Erst danach ist eine seriöse Aussage über Aufwand und Risiko möglich.
Für eine Webanwendung mittlerer Größe, etwa ein Kundenportal mit Anmeldung, einigen Dutzend Seiten und zwei Schnittstellen, rechnen wir mit 4 bis 6 Personentagen, bevor die erste Änderung sinnvoll ist. Die Spanne ergibt sich aus den Bausteinen: 1 bis 2 Tage, um die Anwendung lokal und auf einer Testumgebung lauffähig zu machen, wenn kein Handbuch existiert; 2 Tage, um die Kernabläufe im Code nachzuvollziehen; 0,5 bis 1 Tag für den Stand von Abhängigkeiten und Sicherheitslücken; 0,5 bis 1 Tag für einen schriftlichen Befund mit Risiken und Reihenfolge. Fehlt Code im Repository, weil Änderungen direkt auf dem Server gemacht wurden, kommt der Abgleich beider Stände hinzu.
Was die Einarbeitung kürzt, zeigt ein Einsatz unter günstigen Bedingungen. Beim FinTech-Backend für eine Versicherungs-App konnten wir die ersten Tickets in der ersten Woche ziehen: Der Auftrag war scharf umrissen, die API-Verträge gegen die Mobile-App waren klar dokumentiert, und der Stack war uns aus Versicherungs- und Banking-Projekten vertraut. Bei einem verwaisten Projekt gibt es kein internes Team, das Fragen beantwortet, und ob Schnittstellen dokumentiert sind, zeigt sich erst beim Lesen. Planen Sie die Tage oben deshalb ein, statt auf einen schnellen Einstieg zu hoffen.
Achten Sie bei der Wahl des Nachfolgers darauf, dass Sie nicht wieder bei einer einzelnen Person landen. Worin sich ein Team mit eingeplanter Vertretung und dokumentierter Übergabe von einem einzelnen Freelancer unterscheidet, zeigt unser Vergleich MARCODES und Solo-Freelancer.
Die ersten Wochen
Erst stabilisieren, dann ändern
Die erste Auslieferung des neuen Dienstleisters enthält keine neue Funktion. Sie bringt den unveränderten Code über den neuen Weg live, etwa über eine eingerichtete Pipeline oder ein dokumentiertes Skript. Klappt das, ist bewiesen, dass Zugänge, Server und Auslieferung zusammenpassen. Klappt es nicht, haben Sie den Fehler in einem Moment gefunden, in dem keine Änderung dazwischenfunkt.
Danach folgen in dieser Reihenfolge:
Überwachung: Eine Prüfung von außen meldet Ausfälle an Sie und an den Dienstleister, nicht an das Postfach des Vorgängers.
Sicherheitsupdates: Offene Lücken in Betriebssystem, PHP und Paketen werden geschlossen, in kleinen Schritten mit Test. Warum kleine Updates weniger Schaden anrichten als ein großer Sprung, begründet der Beitrag Patch-Disziplin.
Wiederherstellung: Ein Backup wird einmal vollständig auf einer Testumgebung zurückgespielt, mit Stoppuhr.
Tests an den Änderungsstellen: Bevor die erste fachliche Änderung kommt, halten Tests fest, was der Code an dieser Stelle tut. Das Vorgehen beschreibt Legacy-Code ohne Tests: So sichern Sie Änderungen ab.
Diese Phase dauert je nach Zustand einige Wochen und gehört in eine laufende Wartung mit festen Updates und geprüften Backups. Neue Funktionen haben in dieser Zeit Pause. Wer drängt, weil ein Kunde wartet, sollte wissen, dass jede Änderung vor der Stabilisierung auf einem System landet, dessen Zustand noch niemand kennt.
Danach
Vorsorge für das nächste Mal
Das ausgefüllte Inventar bleibt im Unternehmen und wird bei jeder Änderung an Konten oder Diensten nachgetragen. Zwei Prüfungen im Jahr reichen, um es aktuell zu halten: Liegen alle Zugänge noch bei Ihnen, und hat außer dem Hauptentwickler jemand eine Version ausgeliefert? Die weiteren Maßnahmen, von Vertretung bis Dokumentation, stehen im eingangs verlinkten Beitrag zum Bus-Faktor.
Nachgefragt
Häufige Fragen
-
Steht Ihr Unternehmen im Vertrag mit dem Hoster, setzt der Hoster nach Prüfung Ihrer Identität das Root-Passwort zurück oder lässt Sie einen eigenen SSH-Schlüssel über die Konsole im Kundenkonto hinterlegen. Läuft der Vertrag auf den Entwickler, braucht es dessen Zustimmung zur Vertragsübernahme oder eine Klärung über den Vertrag, den Sie mit ihm haben. Kopieren Sie in jedem Fall zuerst Datenbank und Dateien, bevor am Server etwas geändert wird.
-
Das hängt weniger von der Größe als vom Zustand ab: Gibt es ein Handbuch zum Starten und Ausliefern, liegt der ganze Code im Repository, sind die Versionen aktuell? Für eine mittelgroße Webanwendung ohne Dokumentation sind einige Personentage realistisch, bevor die erste Änderung kommt. Ein schriftlicher Befund am Ende der Einarbeitung zeigt, wo die Risiken liegen.
-
Am Anfang einer Übernahme fehlt das Wissen, um das zu entscheiden. Erst wenn die Anwendung wieder unter Ihrer Kontrolle läuft und ein Befund vorliegt, lässt sich vergleichen, was der Erhalt und was ein Neubau kosten würde. Wer vorher neu baut, verliert dabei die Fachlogik, die nur im alten Code steht.
Wer übernimmt, wenn wieder jemand ausfällt?
Vertretung, Übergabe-Dokumentation im Repository und Verträge mit einer Gesellschaft statt mit einer Privatperson: Der Vergleich zeigt, was sich gegenüber einem einzelnen Freelancer ändert.
Nachweise
Quellen und Stand
Stand: 12.08.2026. Die Aufwandsangabe zur Einarbeitung ist eine Schätzung für eine Anwendung mittlerer Größe und ersetzt keinen Befund am konkreten Code. Die Hinweise zu Domain und Urheberrecht sind keine Rechtsberatung.
Artikel teilen