Wenn der Dienstleister verschwindet: Wartungsnachfolge für Eigenentwicklungen sauber geregelt
Photo: alter Serverschrank Keller Industriehalle Kabel Wartung, via blog.hadiko.de
In vielen deutschen Mittelstandsunternehmen läuft eine spezielle Kategorie von Software, über die kaum noch jemand spricht: fachkundig programmierte Eigenentwicklungen oder Individualanpassungen, die vor zehn, fünfzehn oder zwanzig Jahren von einer lokalen Softwarefirma gebaut wurden. Das System läuft stabil, die Belegschaft kennt es, die Prozesse sind darauf ausgerichtet. Doch der ursprüngliche Dienstleister existiert nicht mehr – insolvent, übernommen, oder schlicht vom Markt verschwunden. Was bleibt, ist ein Wartungsvertrag ohne Vertragspartner und ein System ohne offizielle Betreuung.
Die stillschweigende Lücke im Betrieb
Die Situation ist verbreiteter, als die Zahlen zur Digitalisierung vermuten lassen. Wartungsverträge laufen oft formal weiter, weil sie auf einen Rechtsnachfolger übergegangen sind oder weil ein neues Systemhaus die Rechnungen einfach weiterstellt. Technisch betreut wird aber längst niemand mehr. Updates finden nicht statt, Schnittstellen werden nicht gepflegt, und beim ersten gravierenden Fehler steht das Unternehmen ohne verlässlichen Ansprechpartner da.
Besonders heikel wird es, wenn der Vertrag nur als Rahmenvereinbarung existiert und die eigentliche Leistung – etwa die Pflege spezifischer Module – mündlich vereinbart wurde. Dann ist nicht nur die Wartung, sondern auch die Rechtslage unklar. Wer haftet bei einem Ausfall? Wer darf den Quellcode ändern? Wer besitzt die Dokumentation?
Rechte klären, bevor Technik geklärt wird
Der erste Schritt sollte kein technischer, sondern ein rechtlicher sein. Unternehmen sollten ihre Vertragslage systematisch aufnehmen: Welche Nutzungsrechte am Quellcode wurden eingeräumt? Gab es eine Escrow-Vereinbarung – also die Hinterlegung von Quellcode und Dokumentation bei einem Treuhänder für den Fall der Insolvenz? Wurden Säumnis- oder Insolvenzklauseln vereinbart, die dem Kunden Rechte bei Wegfall des Dienstleisters einräumen?
Fehlt eine Escrow-Lösung, ist die Situation schwieriger, aber nicht aussichtslos. Oft lässt sich über den Insolvenzverwalter oder über Nachfolgegesellschaften der ursprüngliche Codestand noch beschaffen. In manchen Fällen existiert der Quellcode nur in Teilen oder gar nicht mehr – dann muss die Nachfolge von Grund auf geplant werden. Auch die Frage der Übertragbarkeit von Lizenzen eingesetzter Drittkomponenten, etwa Datenbanken oder Laufzeitumgebungen, verdient in dieser Phase Aufmerksamkeit.
Die technische Bestandsaufnahme
Parallel dazu empfiehlt sich eine nüchterne Bestandsaufnahme des Systems selbst. Dazu gehört die Frage, ob überhaupt ein aktueller Quellcode vorliegt, in welcher Form die Dokumentation existiert und welche Abhängigkeiten das System hat – vom Betriebssystem über die Datenbank bis zu individuellen Schnittstellen. Ein System, das auf einer längst nicht mehr unterstützten Laufzeitumgebung basiert, stellt andere Anforderungen an die Nachfolge als eine Anwendung mit modernem Fundament, bei der nur die Betreuung fehlt.
Hier kann eine strukturierte Risikoabschätzung nach dem Vorbild der ESKUG-Systematik – also der risikoorientierten Betrachtung besonders schutzbedürftiger und kritischer Systeme – hilfreich sein. Im Kern geht es darum, das Altsystem anhand von drei Dimensionen einzustufen: Wie kritisch ist es für den Geschäftsbetrieb? Wie groß ist das Sicherheitsrisiko bei fehlender Wartung? Und wie hoch ist der Aufwand einer Ablösung? Daraus lässt sich eine Priorisierung ableiten, die verhindert, dass das Unternehmen alle vier Eigenentwicklungen gleichzeitig und damit erfolglos modernisieren will.
Drei Wege der Nachfolge
Für die technische Nachfolge haben sich in der Praxis drei Muster bewährt. Erstens: die Übernahme durch ein neues Systemhaus. Das ist am schnellsten, setzt aber voraus, dass Quellcode, Dokumentation und Wissen überhaupt verfügbar sind. Gute Dienstleister verlangen für die Übernahme eines fremden Codes einen Assessment-Zeitraum – das ist fair und sollte einkalkuliert werden.
Zweitens: die schrittweise Ablösung. Kritische Funktionen werden in ein neues System überführt, das Altsystem bleibt solange im reduzierten Betrieb. Dies reduziert das Ausfallrisiko, verlangt aber eine klare Übergangsarchitektur, damit keine neuen Schnittstellen-Insellösungen entstehen.
Drittens: die kontrollierte Stilllegung mit funktionaler Ersetzung durch Standardsoftware. Das ist der sauberste Weg, scheitert aber häufig an speziellen Fachfunktionen, die keine Standardlösung abbildet. Genau deshalb lohnt sich die vorherige Bestandsaufnahme: Sie zeigt, welche Anteile des Systems tatsächlich individuell sind und welche ohnehin nur Standardprozesse abbilden.
Escrow und Wissenstransfer neu denken
Aus der Erfahrung der Dienstleister-Erlosigkeit lässt sich eine einfache Regel ableiten: Verträge mit neuen Dienstleistern sollten von Anfang an eine Escrow-Vereinbarung vorsehen oder zumindest das vertragliche Recht auf regelmäßige Herausgabe von Quellcode und Dokumentation festzurren. Ergänzend empfiehlt sich ein jährlicher Wissenstransfer-Check: Liegt der aktuelle Codestand hinterlegt? Funktioniert die Wiederherstellung aus der Hinterlegung tatsächlich?
Auch intern sollte das Unternehmen den Wissensstand sichern. Wer im Betrieb die Eigenentwicklung fachlich bedient, welche Sonderfälle im Code abgebildet sind, welche Schnittstellen von Partnern genutzt werden – diese Informationen gehören in ein Dokument, das nicht im Kopf einer einzigen Person existiert.
Fazit: Nachfolge ist ein Projekt, kein Notfall
Der Wegfall eines Wartungsdienstleisters für eine Eigenentwicklung ist kein Grund zur Panik, aber auch kein Zustand, den man jahrelang aushalten sollte. Wer die Vertragslage klärt, das System risikobasiert einstuft und einen der drei Nachfolgewege bewusst wählt, verwandelt einen latenten Betriebsausfall in ein planbares Projekt. Wer hingegen wartet, bis das System im kritischen Moment ausfällt, verhandelt aus einer Position, in der weder Zeit noch Optionen zur Verfügung stehen.
