Software-Übergabe - was passiert, wenn dein Dienstleister geht?

Was passiert, wenn dein Entwicklungspartner in zwei Jahren nicht mehr existiert, das Team wechselt oder du einfach unzufrieden bist? Wer diese Frage erst stellt, wenn es so weit ist, hat meist schon verloren. Die Antworten gehören in den Vertrag, nicht in eine Krisensitzung.

Was Vendor-Lock-in in der Softwareentwicklung bedeutet

Vendor-Lock-in entsteht, wenn du faktisch nicht mehr wechseln kannst, ohne bei null anzufangen - weil dir der Quellcode fehlt, die Dokumentation unvollständig ist oder die Software auf proprietärer Infrastruktur des Anbieters läuft, die nicht übertragbar ist. Das Risiko ist nicht theoretisch: Gerade bei günstigen Angeboten sparen Anbieter genau an den Stellen, die im Ernstfall teuer werden.

Quellcode-Rechte vertraglich klären

Standardmäßig solltest du als Auftraggeber die vollständigen Nutzungs- und Verwertungsrechte am Quellcode erhalten - nicht nur eine Lizenz zur Nutzung der fertigen Software. Prüfe im Vertrag konkret:

Wem gehört der Quellcode nach Projektabschluss?
Hast du Zugriff auf das vollständige Repository inklusive Versionshistorie, nicht nur auf ein finales Zip-Archiv?
Gilt das auch für eingesetzte Bibliotheken und Frameworks Dritter, oder nur für den selbst geschriebenen Code?
Ist der Übergang der Rechte an den vollständigen Abschluss der Zahlung geknüpft, oder greift er bereits bei Teilabnahmen?

Dokumentation ist keine Kür, sondern Bedingung

Code ohne Dokumentation ist für einen neuen Entwickler kaum wartbar. Verlange als Projektbestandteil - nicht als optionales Extra:

eine technische Architekturübersicht
eine Dokumentation der Deployment- und Infrastruktur-Konfiguration
Zugangsdaten und Verantwortlichkeiten für alle genutzten Drittdienste (Hosting, APIs, Domains)
eine Liste aller eingesetzten Bibliotheken, Frameworks und deren Lizenzbedingungen

Frag im Zweifel nach einem Muster aus einem früheren, abgeschlossenen Projekt. Ein Anbieter, der eine übergebene Dokumentation vorweisen kann, hat den Prozess schon einmal durchlaufen - einer, der ausweicht, wahrscheinlich nicht.

Der Übergabe-Passus im Vertrag: Was konkret geregelt sein sollte

Ein reiner Verweis auf "vollständige Übergabe bei Projektende" reicht in der Praxis nicht. Konkret gehören folgende Punkte in den Vertrag oder ein Übergabe-Protokoll als Anhang:

Frist: Innerhalb welcher Zeit nach Kündigung oder Projektende erfolgt die vollständige Übergabe?
Umfang: Quellcode, Datenbank-Schemata, Testdaten, CI/CD-Konfiguration, Umgebungsvariablen (ohne Geheimnisse im Klartext im Vertrag selbst), Zugangsdaten zu allen Drittsystemen.
Format: Übergabe über ein Repository, auf das du direkten Zugriff erhältst - nicht per E-Mail-Anhang, der schnell veraltet.
Ansprechpartner für Rückfragen: Ein definierter Zeitraum, in dem der bisherige Anbieter für Verständnisfragen zur Codebasis erreichbar bleibt, idealerweise gegen ein vorher vereinbartes, begrenztes Stundenkontingent.
Vertragsstrafe bei Verzug: Ein klarer, wirtschaftlich spürbarer Anreiz, falls die Übergabe verschleppt wird.

Laufender Know-how-Transfer statt Big-Bang-Übergabe

Eine Übergabe am letzten Projekttag ist fast immer unvollständig. Besser: Vereinbare regelmäßige, dokumentierte Übergabepunkte während des Projekts, zum Beispiel nach jedem größeren Meilenstein. So bleibt das Wissen nachvollziehbar, statt sich am Ende in einem einzigen Übergabetermin zu verdichten, den niemand vollständig verarbeiten kann.

Konkret bedeutet das: Nach jedem Meilenstein wird der aktuelle Stand des Repositories, der Dokumentation und der Infrastruktur-Konfiguration geprüft und bestätigt - nicht nur der fachliche Funktionsumfang. So fällt eine unvollständige Übergabe schon während des Projekts auf, nicht erst beim Ausstieg.

Infrastruktur: Wem gehören die Accounts?

Ein oft übersehener Punkt: Wenn der Dienstleister Hosting, Domain oder Datenbank-Accounts in seinem eigenen Namen anlegt, bist du technisch von ihm abhängig, selbst wenn dir der Code gehört. Bestehe darauf, dass zentrale Infrastruktur-Accounts auf dein Unternehmen laufen - der Dienstleister erhält darauf Zugriffsrechte, nicht umgekehrt.

Das betrifft insbesondere:

Domain-Registrierung
Hosting- und Cloud-Accounts (AWS, Azure, GCP oder vergleichbare Anbieter)
Produktionsdatenbanken
Accounts für Zahlungsdienstleister, E-Mail-Versand und andere kritische Drittdienste

Auch wenn das im Projektverlauf mehr initialen Abstimmungsaufwand bedeutet, ist es der zuverlässigste Schutz gegen faktische Abhängigkeit - unabhängig davon, was der Vertrag zu Codes-Rechten sagt.

Was tun, wenn der Anbieter die Übergabe verweigert oder verschleppt?

Selbst mit gutem Vertrag kann es vorkommen, dass ein Anbieter die Übergabe hinauszögert - oft, weil intern die Kapazität fehlt, oder weil ein offener Streitpunkt (etwa eine strittige Schlussrechnung) als Druckmittel genutzt wird. Für diesen Fall hilft es, vorab zu wissen, welche Schritte zur Verfügung stehen:

Fristsetzung mit Verweis auf den Vertrag: Eine schriftliche, konkrete Fristsetzung unter Bezug auf den vereinbarten Übergabe-Passus schafft Klarheit und Nachweisbarkeit.
Zurückbehaltungsrecht bei Zahlung: Wenn die Übergabe vertraglich an einen Zahlungsmeilenstein geknüpft ist, kannst du die letzte Rate bis zur vollständigen, geprüften Übergabe zurückhalten.
Rechtliche Durchsetzung: Bei anhaltender Verweigerung bleibt der Weg über einen Anwalt - deutlich einfacher, wenn der Vertrag die Übergabe konkret und mit Fristen geregelt hat, statt vage zu bleiben.

Je konkreter der Vertrag von Anfang an war, desto seltener wird dieser Eskalationsweg überhaupt nötig.

Proprietäre Frameworks als versteckter Lock-in

Ein Lock-in muss nicht offensichtlich sein. Manche Anbieter setzen auf ein selbst entwickeltes, internes Framework oder Baukastensystem, das nur ihre eigenen Entwickler beherrschen. Der Quellcode gehört dir formal, aber kein anderer Anbieter kann ihn in vertretbarer Zeit übernehmen, weil die Architektur auf firmeneigenen Bausteinen statt auf verbreiteten, dokumentierten Standardtechnologien beruht. Frage deshalb explizit, mit welchen Technologien gearbeitet wird, und ob es sich um verbreitete, am Markt gängige Frameworks handelt.

Fazit

Die Frage "was, wenn der Dienstleister geht" lässt sich nicht im Nachhinein beantworten, sondern nur vorab vertraglich regeln. Quellcode-Rechte, laufende Dokumentation, ein konkreter Übergabe-Passus und eigene Infrastruktur-Accounts sind der Unterschied zwischen einem Wechsel, der ein paar Wochen dauert, und einem, der bei null anfängt.

Häufig gestellte Fragen

Was ist Vendor-Lock-in bei Softwareprojekten?

Vendor-Lock-in bedeutet, dass du faktisch nicht mehr zu einem anderen Anbieter wechseln kannst, ohne bei null anzufangen - meist weil dir der Quellcode, die Dokumentation oder die Kontrolle über die Infrastruktur fehlt.

Wem gehört der Quellcode nach Abschluss eines Softwareprojekts?

Das hängt vom Vertrag ab. Standardmäßig solltest du die vollständigen Nutzungs- und Verwertungsrechte am Quellcode erhalten, inklusive Zugriff auf das vollständige Repository mit Versionshistorie - nicht nur eine Lizenz zur Nutzung der fertigen Software.

Was sollte im Übergabe-Passus eines Entwicklungsvertrags konkret stehen?

Eine klare Frist für die vollständige Übergabe nach Projektende, der genaue Umfang (Quellcode, Datenbank-Schemata, Infrastruktur-Zugänge), das Übergabeformat, ein Ansprechpartner für Rückfragen zur Codebasis, und idealerweise eine Vertragsstrafe bei Verzug.

Warum sollten Infrastruktur-Accounts auf mein Unternehmen laufen statt auf den Dienstleister?

Wenn Hosting-, Domain- oder Datenbank-Accounts im Namen des Dienstleisters laufen, bist du technisch von ihm abhängig, selbst wenn dir der Code rechtlich gehört. Zentrale Accounts sollten auf dein Unternehmen laufen, der Dienstleister erhält darauf nur Zugriffsrechte.

Wann sollte die Wissensübergabe im Projekt stattfinden?

Nicht erst am letzten Projekttag. Besser sind regelmäßige, dokumentierte Übergabepunkte nach jedem größeren Meilenstein, damit Wissen nachvollziehbar bleibt statt sich in einem einzigen, kaum verarbeitbaren Termin zu verdichten.