Der Freelancer antwortet seit Wochen nicht mehr. Die Agentur hat Insolvenz angemeldet oder sich vom Projekt zurückgezogen. Der Entwickler, der als Einziger wusste, wie alles zusammenhängt, hat das Unternehmen verlassen. Die Software läuft noch, aber niemand kann sie ändern, und die nächste offene Rechnung beim Hoster ist vielleicht die letzte.
Dieser Artikel beschreibt, wie Sie in dieser Lage vorgehen: was in den ersten 48 Stunden passieren muss, wie Sie die Frage nach den Rechten am Code einordnen, was eine Bestandsaufnahme leistet und wie Sie danach entscheiden, ob weitergebaut, saniert oder neu gebaut wird. Ein eigener Abschnitt behandelt Shopware-Shops, die bei einer Agentur festhängen. Am Ende steht, wie eine Übernahme abgerechnet wird und wovon die Dauer abhängt.
Die Reihenfolge ist bei jeder Software-Rettung dieselbe: erst sichern, dann verstehen, dann entscheiden. Wer die Schritte vertauscht, bezahlt dafür.
Die ersten 48 Stunden: Zugänge sichern
Solange die Anwendung läuft, wirkt die Lage weniger dringend, als sie ist. Das Risiko liegt in Konten, die auf den Namen des bisherigen Dienstleisters laufen: Läuft dort eine Zahlung nicht mehr, wird ein Server abgeschaltet, eine Domain nicht verlängert oder ein Zertifikat nicht erneuert. Dann steht die Anwendung, und ohne Zugang lässt sie sich nicht wieder starten.
Gehen Sie deshalb diese Liste durch, bevor Sie über Code oder neue Funktionen sprechen:
| Bereich | Was Sie brauchen | Typische Falle |
|---|---|---|
| Repository | Administrator-Zugang auf ein Konto Ihres Unternehmens, vollständige Kopie mit allen Branches | Der Code liegt im privaten Konto des Entwicklers; der Stand in Produktion ist nie eingecheckt worden |
| Hosting und Server | Zugang zum Kundenkonto beim Hoster, nicht nur zum Server; Klarheit, wer die Rechnung zahlt | Der Vertrag läuft auf die Agentur, bei Zahlungsausfall wird abgeschaltet |
| Domain und DNS | Zugang beim Registrar und zur DNS-Verwaltung; Ihr Unternehmen als Inhaber der Domain | Die Agentur ist als Inhaber eingetragen, die Verlängerung hängt an ihrer Zahlungsart |
| Datenbank | Aktueller, vollständiger Export, gespeichert außerhalb der bisherigen Infrastruktur | Es gibt nur den laufenden Server, keine Kopie an einem zweiten Ort |
| Backups | Wissen, wo Backups liegen, wie oft sie entstehen und ob sie sich wiederherstellen lassen | Backups laufen seit Monaten nicht mehr, oder niemand hat je eine Wiederherstellung getestet |
| App-Store-Konten | Zugang zu den Entwicklerkonten bei Apple und Google, auf denen die App veröffentlicht ist | Die App liegt im Konto der Agentur; eine Übertragung geht nur mit deren Mitwirkung |
| Drittanbieter-Konten | Zahlungsanbieter, Cloud-Dienste, Karten, Analyse, Shop-Plattform, Lizenzen für Erweiterungen | Lizenzen und Verträge laufen auf die Agentur und enden mit ihr |
| API-Schlüssel und Secrets | Liste aller Schlüssel und Zugangsdaten, die die Anwendung nutzt, und wo sie hinterlegt sind | Schlüssel stehen nur in Konfigurationsdateien auf dem Server oder in der Build-Pipeline der Agentur |
| Mailversand | Zugang zum Mail-Dienst oder SMTP-Konto; die DNS-Einträge für den Versand | Bestellbestätigungen und Passwort-Links fallen aus, weil das Konto des Dienstleisters gekündigt wurde |
Drei Regeln helfen dabei.
Erst kopieren, dann ändern. Sichern Sie Code und Datenbank zuerst an einem Ort, der Ihnen gehört. Erst danach ändern Sie Passwörter und tauschen Schlüssel aus, die der bisherige Dienstleister kennt. Wer einen API-Schlüssel austauscht, bevor er weiß, wo er überall verwendet wird, legt im Zweifel selbst die Produktion lahm.
Alles an einem Ort ablegen. Neue Zugangsdaten gehören in einen Passwortmanager Ihres Unternehmens, nicht in E-Mails und nicht in den Kopf einer einzelnen Person. Sonst wiederholt sich die Lage beim nächsten Wechsel.
Schriftlich anfragen. Ist der bisherige Dienstleister noch erreichbar, bitten Sie schriftlich und mit Frist um die Herausgabe von Zugängen, Quellcode und Dokumentation. Bei einer Insolvenz ist die Insolvenzverwaltung der Ansprechpartner. Eine nachvollziehbare Anfrage hilft auch, falls die Frage nach den Rechten später geklärt werden muss.
Wem gehört der Code?
Hinweis: Dieser Abschnitt ist keine Rechtsberatung. Er beschreibt allgemein, an welchen Stellen sich die Frage entscheidet. Ob und welche Ansprüche Sie in Ihrem Fall haben, klären Sie bitte mit einer Anwältin oder einem Anwalt für IT-Recht.
Dass Sie eine Software bezahlt haben, heißt nicht automatisch, dass Ihnen der Quellcode gehört oder dass Sie ihn von jemand anderem weiterentwickeln lassen dürfen. Computerprogramme sind urheberrechtlich geschützt (§§ 69a ff. UrhG). Bei extern entwickelter Software erhält der Auftraggeber die Nutzungsrechte, die ihm vertraglich eingeräumt werden. Ist der Vertrag dazu ungenau, richtet sich der Umfang im Zweifel nach dem Zweck, den beide Seiten mit dem Vertrag verfolgt haben (§ 31 Abs. 5 UrhG). Bei Software, die angestellte Entwickler im eigenen Unternehmen schreiben, liegen die wirtschaftlichen Rechte dagegen grundsätzlich beim Arbeitgeber (§ 69b UrhG).
Für die Übernahme sind vor allem drei Fragen wichtig:
- Was steht im Vertrag zu den Nutzungsrechten? Ausschließlich oder einfach, zeitlich und räumlich unbeschränkt, mit dem Recht zur Bearbeitung durch Dritte? Das letzte Recht brauchen Sie, damit ein anderer Entwickler weiterbauen darf.
- Ist die Herausgabe des Quellcodes geregelt? Viele Verträge sagen dazu nichts. Ob dann ein Anspruch besteht, hängt von den Umständen ab und lässt sich nicht pauschal beantworten.
- Was gehört gar nicht dem Dienstleister? Open-Source-Bibliotheken unterliegen ihren eigenen Lizenzen, gekaufte Erweiterungen den Bedingungen ihres Herstellers. Für sie muss geklärt werden, auf wen die Lizenz läuft, nicht wem der Code gehört.
Praktisch gilt: Was Sie bereits haben, etwa einen Repository-Zugang oder eine Kopie vom Server, sichern Sie sofort. Was Sie nicht haben, fordern Sie schriftlich an. Die rechtliche Bewertung läuft parallel zur technischen Bestandsaufnahme und muss sie nicht aufhalten.
Was in künftige Verträge gehört
Die Übernahme ist ein guter Anlass, die nächsten Verträge anders aufzusetzen:
- Repository, Hosting, Domain und alle Drittanbieter-Konten laufen auf Ihr Unternehmen. Der Dienstleister erhält Zugang, nicht Eigentum.
- Nutzungsrechte sind ausdrücklich geregelt, einschließlich des Rechts, die Software durch Dritte bearbeiten zu lassen.
- Quellcode und Dokumentation werden nach jeder Etappe übergeben, nicht erst am Projektende.
- Die Dokumentation ist Teil der Leistung: Wie wird die Anwendung gebaut, ausgeliefert und betrieben?
Bestandsaufnahme: Was ein Code-Audit prüft
Ist der Betrieb gesichert, folgt die Frage, wie es um die Software tatsächlich steht. Nach einem Dienstleisterausfall weiß das meist niemand im Unternehmen genau, und die letzten Statusberichte sind selten eine verlässliche Grundlage. Ein Code-Audit schafft hier eine sachliche Antwort.
Ich prüfe dabei diese Bereiche:
- Vollständigkeit: Entspricht der Code im Repository dem, was in Produktion läuft? Lässt sich die Anwendung aus dem Repository bauen und starten, ohne Wissen, das nur im Kopf des Vorgängers existierte?
- Fertigstellungsgrad: Was ist von dem umgesetzt, was beauftragt war? Was ist angefangen, was fehlt ganz?
- Architektur: Passt die Struktur zur Aufgabe? Ist das Datenmodell tragfähig, oder bildet es Ihre Abläufe falsch ab?
- Codequalität und Tests: Ist der Code nachvollziehbar? Gibt es automatische Tests, und decken sie die wichtigen Abläufe ab?
- Abhängigkeiten: Welche Frameworks und Bibliotheken werden genutzt, in welchen Versionen? Welche werden nicht mehr gepflegt, für welche gibt es bekannte Sicherheitslücken?
- Sicherheit: Zugangsdaten im Code, fehlende Rechteprüfungen, ungeprüfte Eingaben, Umgang mit personenbezogenen Daten.
- Betrieb: Wie wird ausgeliefert, gibt es Backups, Monitoring und Protokolle? Würde jemand einen Ausfall bemerken, bevor ein Kunde anruft?
- Schnittstellen: Welche Systeme sind angebunden, und wie verhält sich die Anwendung, wenn eines davon nicht antwortet?
Der Bericht ist für Entscheider geschrieben, nicht für Entwickler. Er enthält eine Zusammenfassung auf einer Seite, eine Einschätzung je Bereich, die Risiken geordnet nach Dringlichkeit, eine Liste dessen, was fertig ist und was fehlt, und eine Empfehlung mit den realistischen Optionen. Der technische Teil mit Details für den nächsten Entwickler steht im Anhang. Mit diesem Bericht können Sie entscheiden, auch wenn Sie selbst keinen Code lesen.
Weiterbauen, sanieren oder neu bauen
Aus dem Audit ergibt sich in der Regel eine von drei Richtungen. Sie schließen sich nicht immer aus: Häufig wird ein Teil saniert und ein anderer neu gebaut.
| Weg | Passt, wenn | Worauf Sie achten sollten |
|---|---|---|
| Weiterbauen | Das Fundament ist solide, Lücken betreffen Funktionen, nicht die Struktur; der Stack wird gepflegt | Zuerst Tests und Dokumentation für die kritischen Abläufe, damit neue Funktionen nichts zerbrechen |
| Sanieren | Das Datenmodell trägt, aber Qualität, Abhängigkeiten oder Sicherheit sind mangelhaft | Schritt für Schritt bei laufendem Betrieb, jede Etappe mit echten Daten geprüft |
| Neu bauen | Das Datenmodell passt nicht zu den Abläufen, der Stack ist veraltet, es gibt grundlegende Sicherheitsmängel | Die alte Anwendung enthält Geschäftsregeln, die nirgends sonst dokumentiert sind |
Diese Fragen helfen bei der Einordnung:
- Läuft die Anwendung in Produktion? Eine Software, an der täglich Bestellungen oder Kundenanfragen hängen, wird anders behandelt als ein halbfertiges Projekt, das noch niemand nutzt. Bei laufendem Betrieb hat Stabilität Vorrang, ein Neubau entsteht dann parallel.
- Trägt das Datenmodell? Fehler im Code lassen sich beheben. Ein Datenmodell, das Ihre Abläufe falsch abbildet, zieht sich durch jede Funktion und ist der häufigste Grund für einen Neubau.
- Wird der Technologie-Stack noch gepflegt? Ein Framework ohne Sicherheitsupdates ist ein Risiko, das mit jedem Monat wächst. Liegt nur ein Versionssprung an, ist das Sanierung. Ist die Technik am Ende ihrer Lebenszeit, wird es eine Legacy-Modernisierung oder ein Neubau.
- Wie viel ist wirklich fertig? Ein Projekt, das fast fertig wirkt, ist es oft nicht. Die fehlenden Teile sind häufig die schwierigen: Sonderfälle, Fehlerbehandlung, Schnittstellen.
- Was kostet das Verstehen? Wenn jede Änderung eine Woche Einarbeitung in schwer lesbaren Code erfordert, ist ein Neubau mit dem Gelernten auf Dauer günstiger.
Eine Frage gehört nicht auf diese Liste: wie viel bereits investiert wurde. Das Geld ist ausgegeben, egal wie Sie sich entscheiden. Maßgeblich ist allein, welcher Weg ab heute weniger kostet und schneller zu einer Software führt, die Sie selbst in der Hand haben.
Ein Neubau ist kein Scheitern, wenn er auf einem Audit beruht. Das alte Projekt ist dann die genaueste Anforderungsbeschreibung, die Sie je hatten: Sie wissen, welche Abläufe gebraucht werden, wo die Sonderfälle liegen und was nicht funktioniert hat.
Sonderfall Shop: Shopware-Plugins und Agentur-Erweiterungen
Bei Onlineshops ist die Lage eine eigene. Ein Shopware-6-Shop besteht aus dem Shopware-Kern, gekauften Plugins aus dem Shopware Store, eigenen Plugins und einem Theme der Agentur sowie Schnittstellen zu ERP, Buchhaltung oder Marktplätzen. Steckt das Projekt bei der Agentur fest, betrifft das meist die eigenen Erweiterungen: Sie sind nicht fertig, sie blockieren Updates, oder niemand außer der Agentur versteht sie.
Zusätzlich zur allgemeinen Liste oben sichern Sie bei einem Shop:
- Shopware-Account: Die Lizenzen für Plugins aus dem Shopware Store sind einem Shopware-Account zugeordnet. Läuft er auf die Agentur, gehören die Lizenzen geklärt, bevor das nächste Update ansteht.
- Administrationszugang: ein eigener Admin-Benutzer, nicht der gemeinsame Zugang der Agentur.
- Eigene Plugins und Theme: der Quellcode im Repository, nicht nur die installierte Version auf dem Server.
- Datenbank: Bestellungen, Kunden und Konfiguration, gesichert außerhalb des Shop-Servers.
Im Audit eines Shopware-Projekts schaue ich zusätzlich auf diese Punkte:
- Wie sind die eigenen Plugins gebaut? Nutzen sie die vorgesehenen Erweiterungspunkte von Shopware, oder greifen sie tief in den Kern ein? Das entscheidet, ob der Shop updatefähig bleibt.
- Welche Version läuft, und wie weit ist es zur aktuellen? Jeder ausgelassene Versionssprung macht das nächste Update aufwendiger. Läuft der Shop noch auf Shopware 5, gehört die Migration auf Shopware 6 in den Plan, statt weiter in das alte System zu investieren.
- Sind gekaufte Plugins noch gepflegt? Ein Store-Plugin, das seit Jahren kein Update erhalten hat, blockiert früher oder später ein Shopware-Update.
- Wie wird ausgeliefert? Gibt es ein nachvollziehbares Deployment aus dem Repository, oder wurden Änderungen direkt auf dem Server gemacht? Im zweiten Fall weicht der Stand im Repository oft vom Live-Shop ab.
- Was machen die Schnittstellen? Laufen Bestellungen, Bestände und Rechnungen zuverlässig zwischen Shop und ERP, oder gleicht jemand täglich von Hand ab?
Fehlen Anbindungen oder laufen sie unzuverlässig, ist das ein eigenes Thema: Wie Shopware-Schnittstellen zu ERP, DATEV oder Marktplätzen updatefähig gebaut werden, steht auf der Leistungsseite.
Was eine Übernahme kostet und wie lange sie dauert
Einen Pauschalpreis für eine Übernahme gibt es nicht, weil der Aufwand vom Zustand abhängt, den vorher niemand kennt. Was es gibt, ist eine Reihenfolge, in der Sie nach jedem Schritt entscheiden, ob und wie es weitergeht:
| Schritt | Was passiert | Abrechnung |
|---|---|---|
| Sicherung | Zugänge übernehmen, Code und Daten kopieren, Backups und Überwachung einrichten | Nach Aufwand, weil der Umfang von den vorhandenen Zugängen abhängt |
| Code-Audit | Bestandsaufnahme und Bericht mit Empfehlung | Festpreis, nach einem kurzen Gespräch klar abgegrenzt |
| Stabilisierung | Kritische Fehler beheben, Deployment und Betrieb absichern | Meist nach Aufwand, weil Fehler erst im Code sichtbar werden |
| Weiterentwicklung | Fehlende Funktionen, Sanierung oder Neubau | In Etappen mit Festpreis pro Etappe |
| Laufender Betrieb | Hosting, Updates, Monitoring, kleine Änderungen | Wartungsvertrag mit vereinbartem Umfang |
Der erste Schritt ist der wichtigste und meist der kleinste. Das Audit ist klar abgegrenzt, damit Sie vor größeren Ausgaben wissen, woran Sie sind. Für die Weiterentwicklung gelten dieselben Regeln wie für jedes andere Softwareprojekt; Größenklassen und Kostentreiber stehen im Artikel Was kostet es, Software entwickeln zu lassen?. Wie der Betrieb danach aussieht und wovon die laufenden Kosten abhängen, steht unter Wartung und Betrieb.
Zur Dauer: Ein Audit ist meist innerhalb weniger Tage möglich. Bei einem akuten Ausfall geht die Sicherung des Betriebs vor, die Bewertung folgt danach. Wie lange Audit und Stabilisierung dauern, hängt von Größe und Zustand der Anwendung ab und steht im Angebot, bevor Sie etwas beauftragen.
Drei Dinge verkürzen eine Übernahme spürbar: vollständige Zugänge, eine Liste der Abläufe, die im Alltag wirklich genutzt werden, und eine Person in Ihrem Unternehmen, die Fragen zu den Abläufen beantworten kann. Was dagegen Zeit kostet, sind fehlende Zugänge und Code, der nur auf einem Server existiert.
Erste Einschätzung ist kostenlos
Wenn Ihr Dienstleister ausgefallen ist oder ein Projekt festgefahren ist, beschreiben Sie die Lage in eigenen Worten: um welche Anwendung es geht, welche Zugänge Sie haben, was gerade nicht funktioniert und wie dringend es ist. Sie erhalten innerhalb von 24 Stunden eine erste Einschätzung, was als Nächstes zu tun ist. Wie Übernahme, Audit und Stabilisierung im Einzelnen ablaufen, steht auf der Seite zur Software-Rettung. Die erste Einschätzung ist kostenlos und unverbindlich.
