Was tun, wenn Ihr Softwarelieferant wegfällt?

Was tun, wenn Ihr Softwarelieferant wegfällt?

Es ist ein Szenario, das in der Schweizer KMU-Landschaft häufiger vorkommt, als man denkt: Ein Unternehmen arbeitet seit fünfzehn, zwanzig Jahren mit demselben Softwarepartner zusammen. Die Lösungen sind über die Jahre gewachsen, tief in die Geschäftsprozesse integriert und laufen zuverlässig. Man ist zufrieden mit der Lösung und der Zusammenarbeit, ein Wechselgedanke ist nie aufgekommen. Und dann ändert sich auf einmal alles – aus Gründen, auf die der Kunde keinen Einfluss hat.

Die Auslöser sind unterschiedlich, das Resultat ist dasselbe. Mal ist es der Konkurs, der ohne Vorwarnung kommt. Mal die Übernahme durch einen grösseren Anbieter, der das Produkt abkündigt oder am Kleinkundengeschäft kein Interesse hat. Mal ein Strategiewechsel, der die Lösung aufs Abstellgleis stellt. Bei kleinen, spezialisierten Anbietern reicht schon der Ausfall der einen Schlüsselperson, der Architekt der die Lösung von Grund auf begleitet hat oder der Senior Entwickler, der die Entwicklung über Jahre geprägt hat. Und immer öfter ist es schlicht die Demografie: Die Inhaber möchten sich aus Altersgründen zurückziehen, eine Nachfolge oder einen Käufer der Firma gibt es nicht.

Doch vielleicht gibt es eine Lösung, man ist ja mit der Software offensichtlich zufrieden: Wie wäre es den Quellcode zu kaufen und die Lösung selbst weiterzuentwickeln und warten?

Was zunächst wie eine faire Geste klingt, ist in Wahrheit eine der anspruchsvollsten Entscheidungen, die ein Verwaltungsrat oder eine Geschäftsleitung treffen kann. Plötzlich stehen Fragen im Raum, die weit über ein Preisschild hinausgehen: Können wir diese Software überhaupt selbst weiterentwickeln? Was ist der Code tatsächlich wert? Und ist die Weiterführung wirklich die beste Option oder nur die bequemste?

Warum diese Situation so tückisch ist

Die beiden Parteien kämpfen mit ungleichen Waffen. Der Anbieter kennt seine Software in- und auswendig: die Architektur, die Altlasten, den tatsächlichen Wartungsaufwand, die stillen Abhängigkeiten von einzelnen Köpfen. Der Kunde kennt vor allem die Oberfläche und die Rechnung, die jedes Jahr pünktlich kommt.

Dazu kommt der Zeitdruck. Wer verkaufen oder liquidieren will, setzt Fristen. Wartungsverträge haben Kündigungstermine. Und die Verlockung ist gross, die Entscheidung schnell zu treffen, um «das Thema vom Tisch zu haben». Genau hier entstehen die teuersten Fehler: Entweder wird ein überhöhter Preis für Code bezahlt, den man vielleicht nie hätte kaufen dürfen oder es wird aus Kostengründen abgelehnt und man hat innert kurzer Zeit ein geschäftskritisches System ohne Wartungspartner.

Ein dritter Punkt wird regelmässig unterschätzt: Lines of Code sind keine Währung. Verkaufsangebote argumentieren gerne mit dem Umfang des Codes und den historischen Entwicklungskosten. Beides sagt wenig über den heutigen Wert aus. Code, der mit Generatoren erzeugt wurde, auf Komponentenbibliotheken aufsetzt oder Funktionen abdeckt, die jede Standardsoftware ab Stange beherrscht, rechtfertigt keinen Individualsoftware-Preis. Gerade mit KI Tools wie Claude Code sind Lines Of Codes »schnell« generiert. Viel relevanter ist die Qualität des Codes und dessen Wartbarkeit.

Die entscheidende Frage: Was ist unverzichtbar und was ist austauschbar?

Der wichtigste Schritt einer Due Diligence ist nicht die Preisverhandlung, sondern die Segmentierung der Systemlandschaft. In fast jedem gewachsenen Setup finden sich zwei Kategorien von Software, die völlig unterschiedlich behandelt werden müssen.

Da ist zum einen der differenzierende Kern: die Lösung, mit der das Unternehmen sein eigentliches Leistungsversprechen erbringt und die es in dieser Form am Markt nicht zu kaufen gibt. Hier ist die Hoheit über den Quellcode oft tatsächlich strategisch, sie bedeutet digitale Autonomie und schützt das Geschäftsmodell.

Die harte Realität ist jedoch meistens, dass der differenzierende Kern gar nicht so gross ist. Features die als USP galten, finden sich bei genauerem Betrachten auch in standardisierten Alternativen.

Und da sind zum anderen die Commodity-Bausteine: Auftragsbearbeitung, Fakturierung, Finanzbuchhaltung, Leistungserfassung. Prozesse, die Dutzende etablierter Standardlösungen abdecken – gepflegt von Herstellern, die gesetzliche Änderungen wie MWST-Anpassungen oder neue Zahlungsstandards von sich aus nachziehen. Wer für solche Module Quellcode kauft, kauft sich die Verantwortung für ein Produkt ein, das er weder verkaufen kann noch selbst weiterentwickeln will. Das einzige Argument für die Beibehaltung ist meist die gewachsenen Schnittstellen und Schnittstellen lassen sich neu bauen.

Diese Trennung verändert die Verhandlung fundamental. Statt über ein Gesamtpaket zu diskutieren, entsteht ein differenziertes Zielbild: den strategischen Kern sichern, die austauschbaren Teile mittelfristig durch Standardsoftware ablösen und die Übergangszeit vertraglich absichern.

Wie eine strukturierte Prüfung abläuft

Eine belastbare Entscheidungsgrundlage entsteht in mehreren Schritten, die aufeinander aufbauen.

Am Anfang steht die Vertrags- und Lizenzanalyse. Welche Rechte hat das Unternehmen heute schon? Was regeln Lizenz- und Wartungsverträge für den Fall der Geschäftsaufgabe? Welche Kündigungsfristen definieren das Zeitfenster für Alternativen? Oft zeigt sich hier, dass die Verhandlungsposition besser ist als gedacht, etwa weil Wartungsverpflichtungen noch laufen oder weil für die Lizenzen bereits erhebliche Summen bezahlt wurden.

Es folgt das technische Assessment mit Source-Code-Review. Nicht jeder Code muss Zeile für Zeile gelesen werden, entscheidend ist die Beurteilung von Architektur, Technologie-Stack und Beherrschbarkeit. Setzt die Lösung auf offene Standards und verbreitete Technologien, für die es am Arbeitsmarkt Fachkräfte gibt? Oder auf proprietäre Konzepte, die nur der bisherige Entwickler versteht? Wie hoch ist der Anteil generierten Codes? Eine solide, vielleicht etwas konservative Architektur ohne exotische Konzepte ist im Ausfallszenario mehr wert als das modernste Framework.

Der dritte Baustein ist die Know-how- und Personalanalyse, erfahrungsgemäss der am meisten unterschätzte Teil. Wurde das Know-how bereits transferiert oder hängt es an einer Person, die heute oder morgen nicht mehr zur Verfügung steht? Reichen die internen Kapazitäten für Wartung, Weiterentwicklung und oft vergessen die Qualitätssicherung nach Anpassungen an der Basistechnologie?

Darauf aufbauend entsteht die Kostenmodellierung über mehrere Jahre. Der Kaufpreis ist nur die Eintrittskarte. Relevant sind die Gesamtkosten über drei bis fünf Jahre: Weiterentwicklungsaufwand in Personentagen, Lizenz- und Supportkosten, Ramp-up-Effekte bei seltenen Anpassungen, Risikoaufschläge bei Personalwechseln. Wichtig ist die ehrliche Spreizung zwischen Best und Worst Case und eine gesunde Skepsis gegenüber den Aufwandschätzungen des Verkäufers, die naturgemäss optimistisch ausfallen.

Die Verlockung Personal vom bisherigen Anbieter zu übernehmen, muss genau gerechnet werden. Die Personen wissen genau, dass »sie gebraucht werden«. Das bringt sie in eine Position der Stärke was direkten Einfluss auf die Lohnverhandlung und Anstellungskonditionen haben wird.

Am Ende steht der Variantenvergleich: Gesamtkauf, Teilkauf mit Ablösung der Commodity-Bausteine, oder vollständige Neubeschaffung jeweils bewertet nach Kosten, Risiken, Chancen und Zeitachse. Häufig zeigt sich dabei ein überraschendes Bild: Der vermeintlich teure Weg über eine ERP-Neueinführung liegt über mehrere Jahre gerechnet in derselben Grössenordnung oder sogar deutlich tiefer als der Kauf sämtlicher Quellcodes – bringt aber einen Hersteller mit, der die Lösung dauerhaft weiterentwickelt.

Der Einwand, der immer kommt: »Hätte ein Escrow das nicht verhindert?«

Die Idee ist bestechend einfach: Der Hersteller hinterlegt Quellcode und Dokumentation bei einer neutralen Treuhandstelle. Herausgegeben wird das Paket nur, wenn ein vertraglich definiertes Ereignis eintritt – typischerweise Konkurs, Geschäftsaufgabe oder die Einstellung der geschuldeten Wartung. Klingt nach der perfekten Versicherung.

In der Praxis entscheidet sich der Wert eines Escrow-Agreements an zwei Punkten.

Die Kostenstruktur belohnt die falsche Sparsamkeit. Die nackte Hinterlegung ist der günstige Teil. Teuer sind die Leistungen, die aus einem Stück Papier eine funktionierende Versicherung machen: die Aktualisierung bei jedem Release und die technische Verifizierung, ob sich aus dem hinterlegten Stand die produktive Software überhaupt erzeugen lässt. Genau daran wird in der Praxis gespart, zumal die laufenden Kosten in der Regel beim Kunden liegen. Das Resultat ist dann ein Tresor, in dem ein mehrere Jahre alter, unvollständiger Codestand liegt. Ein Escrow ohne Aktualisierungspflicht und Verifizierung ist keine Absicherung, sondern ein gutes Gefühl mit jährlicher Rechnung.

Escrow liefert Code, kein Know-how. Am Tag der Herausgabe steht der Kunde vor exakt derselben Frage wie beim Kaufangebot des scheidenden Lieferanten: Wer soll das jetzt warten und weiterentwickeln? Nur ist der Hersteller dann nicht mehr da, um beim Know-how-Transfer zu helfen. Im geordneten Nachfolgeszenario löst Escrow das Problem nicht, es verschiebt es auf den ungünstigsten Zeitpunkt.

Escrow ist deshalb Prävention, nicht Rettung. Es gehört an den Anfang einer Lieferbeziehung, als fester Bestandteil des Lizenz- oder Wartungsvertrags: mit Aktualisierungspflicht bei jedem Release, einer dem Risiko angemessenen Verifizierungsstufe und eindeutigen Herausgabekriterien.

 

Fünf Empfehlungen aus der Praxis

1.  Beginnen Sie früh. Das Zeitfenster zwischen dem ersten Warnsignal sei es eine Ankündigung, eine Übernahmemeldung oder ausbleibende Releases und dem tatsächlichen Wegfall ist Ihr wichtigstes Kapital. Wer es für eine saubere Anforderungsanalyse und Evaluation nutzt, verhandelt aus einer Position der Stärke statt aus der Not.

2.  Trennen Sie strategisch von austauschbar, bevor Sie über Preise sprechen. Ein Teilkauf ist fast immer verhandelbar aber nur, wenn Sie wissen, welchen Teil Sie wirklich brauchen.

3.  Lassen Sie sich Aufwandschätzungen des Verkäufers nicht als Planungsgrundlage andrehen. Rechnen Sie mit eigenen, konservativen Annahmen und einem expliziten Worst Case.

4.  Denken Sie an die Infrastruktur. Labor-, Test- und Entwicklungsumgebungen, die bisher der Lieferant gestellt hat, gehören mit auf den Prüfstand inklusive Hardware-Alter, Lizenzübertragbarkeit und der strategischen Frage, ob eigene Hardware überhaupt noch zeitgemäss ist oder eine Cloud-Strategie der bessere Weg wäre.

5.  Holen Sie eine unabhängige Aussensicht ein. Nicht, weil Ihre internen Leute es nicht könnten sondern weil sie Teil des Systems sind. Eine externe Prüfung macht Abhängigkeiten sichtbar, die von innen unsichtbar geworden sind, und gibt dem Verwaltungsrat eine Entscheidungsgrundlage, die auch kritischen Rückfragen standhält.

 

Fazit

Der Wegfall eines Softwarelieferanten muss keine Katastrophe sein, er ist eine Investitionsentscheidung, die eine ordentliche Due Diligence verdient. Das gilt für das Quellcode-Kaufangebot des scheidenden Inhabers genauso wie für die Abkündigung nach einer Übernahme oder den Plan B nach einem Konkurs. Wer strukturiert prüft, statt unter Zeitdruck zu reagieren, verwandelt eine binäre Weiterführen-oder-Ablösen-Frage in einen Fahrplan: den strategischen Kern sichern, Austauschbares ablösen, Risiken aktiv managen. Und nicht selten ist das Ergebnis der Prüfung auch ein besserer Preis.