Individualsoftware

Was passiert mit deinem System, wenn die Zusammenarbeit mit einem Anbieter endet?

Kurz gesagt

Wenn du von Anfang an vollen Zugriff auf Quellcode, Repository, Dokumentation und alle Konten hast, kannst du jederzeit wechseln, ohne von einem Anbieter abhängig zu sein. Eine saubere Übergabe umfasst nicht nur den Code, sondern auch die Fähigkeit, das System tatsächlich zu betreiben, dazu gehört ein realistischer Übergabezeitraum, in dem das bisherige Team für Rückfragen erreichbar bleibt. Warnsignal ist, wenn Konten und Zugänge auf den Namen des Anbieters laufen statt auf deinen, dann bist du im Ernstfall handlungsunfähig.

Was du schon vor dem Ernstfall besitzen solltest

Die wichtigste Absicherung gegen eine schwierige Trennung von einem Anbieter richtest du nicht dann ein, wenn die Zusammenarbeit endet, sondern von Anfang an. Dazu gehört der vollständige Quellcode inklusive der Historie im Repository, nicht nur ein Export am Ende. Dazu gehört Dokumentation, die tatsächlich beschreibt, wie das System aufgebaut ist und betrieben wird, nicht nur ein paar veraltete Notizen. Und dazu gehören alle Konten und Zugänge, die für den Betrieb nötig sind: Hosting, Domain, Zertifikate, externe Dienste, die das System nutzt. Wer das erst beim Ausstieg klärt, verhandelt aus einer schwachen Position.

Was eine saubere Übergabe tatsächlich enthält

Eine Übergabe, die den Namen verdient, besteht aus mehr als einem Zip-Ordner mit Code. Dazu gehört der vollständige Quellcode mit seiner Versionshistorie, damit ein neues Team nachvollziehen kann, wie und warum Entscheidungen getroffen wurden. Dazu gehört eine Dokumentation, die den aktuellen Stand beschreibt, nicht den Stand vom Projektstart. Dazu gehören alle Zugangsdaten und Konten, überschrieben auf dich oder direkt in deinem Namen geführt. Und dazu gehört die Bereitschaft des bisherigen Teams, in einem definierten Zeitraum nach dem eigentlichen Ende Rückfragen zu beantworten, weil ein System selten vollständig aus Dokumentation allein verständlich wird.

Code besitzen ist nicht dasselbe wie das System betreiben können

Ein häufiger Irrtum: wer formal den Quellcode besitzt, glaubt, im Ernstfall problemlos wechseln zu können. In der Praxis reicht das oft nicht. Ein System zu betreiben bedeutet auch, zu wissen, wie es deployt wird, welche Umgebungsvariablen und externen Dienste es braucht, welche Besonderheiten es im Betrieb gibt, die nirgendwo im Code stehen, weil sie sich über Zeit als Praxiswissen angesammelt haben. Genau deshalb ist eine Übergabe mehr als eine Dateiübertragung, sie muss auch dieses Betriebswissen mitgeben, sonst hast du zwar den Code, aber niemanden, der das System kurzfristig lauffähig übernehmen kann.

Ein realistischer Übergabezeitraum

Eine gute Übergabe passiert nicht an einem einzigen Tag. Sinnvoll ist ein definierter Zeitraum, in dem das bisherige Team noch erreichbar ist, offene Fragen beantwortet und das neue Team oder den internen Nachfolger einarbeitet. Wie lang dieser Zeitraum sein muss, hängt vom System ab, aber er sollte von Anfang an Teil des Vertrags sein, nicht erst dann verhandelt werden, wenn die Trennung schon feststeht. Das gilt genauso für den laufenden Wartungsvertrag: die gleichen Fragen zu Zugängen und Verantwortlichkeiten, die dort geklärt werden sollten, entscheiden am Ende auch darüber, wie leicht ein Wechsel fällt.

Das Warnsignal für Lock-in

Es gibt ein einzelnes Zeichen, das zuverlässiger ist als jede vertragliche Formulierung: laufen Konten, Domains, Hosting-Zugänge oder Lizenzen auf den Namen des Anbieters statt auf deinen eigenen? Dann bist du faktisch abhängig, selbst wenn dir der Quellcode formal gehört, weil du im Ernstfall erst diese Konten übertragen lassen musst, bevor überhaupt jemand anderes übernehmen kann. Frag das aktiv ab, bevor eine Zusammenarbeit beginnt, nicht erst, wenn sie beendet werden soll. Wer diese Frage ausweicht oder zögert, sagt dir damit indirekt schon die Antwort.

Wie wir das bei abi services handhaben

Bei uns ist die vollständige Übergabe des Quellcodes Standard, nicht eine Sonderleistung, die extra verhandelt werden muss. Konten und Zugänge legen wir auf deinen Namen an, nicht auf unseren, gerade damit du nicht auf die Fortsetzung der Zusammenarbeit mit uns angewiesen bist. Das ist keine Kulanz, sondern die Haltung, dass ein System dir gehören sollte, unabhängig davon, wer es gerade betreut.

Was du vor dem Start klären solltest

Bevor du mit einem Anbieter startest, frag konkret: wem gehören Repository und Code während und nach dem Projekt, auf wessen Namen laufen die Konten, was genau enthält eine Übergabe, und wie lange bleibt das Team danach für Rückfragen erreichbar. Diese vier Fragen sagen mehr über die tatsächliche Abhängigkeit aus als jede Zusicherung im Verkaufsgespräch.