25. August 2026
Was bleibt, wenn der Anbieter verschwindet?
Warum die Frage nach dem Worst Case in jede Plattformentscheidung gehört, und warum die Antwort weniger von der Lizenz abhängt, als die meisten annehmen.
Die Entscheidung, die länger wirkt als der Vertrag
Jede Software-Entscheidung ist eine Wette auf die Zukunft eines Anbieters. Bewertet werden Features, Preise, Referenzkund*innen und das Support-Versprechen. Geprüft wird, ob die Plattform heute leistet, was gebraucht wird. Seltener geprüft wird, was in fünf Jahren gilt, wenn sich die Rahmenbedingungen verschoben haben, und was bleibt, wenn der Anbieter nicht mehr da ist.
Für jede Organisation, die digitale Infrastruktur betreibt und erwartet, dass sie länger hält als der nächste Budgetzyklus, ist das eine zentrale Frage. Die Antwort, oder das Fehlen einer Antwort, entscheidet darüber, ob eine Organisation in der Krise manövrierfähig bleibt.
Software-Entscheidungen werden für heute getroffen. Ihre Konsequenzen wirken allerdings für die nächsten fünf bis zehn Jahre. Diese Asymmetrie ist das eigentliche Risiko.
Drei Arten zu scheitern
Die Softwarelandschaft liefert genügend Präzedenzfälle, um das Muster kritischer Abhängigkeiten zu verstehen. Die neuen Bedingungen treten selten plötzlich ein. Sie treten schleichend ein und sind deshalb besonders schwer zu erkennen.
01. Der Anbieter wird übernommen, und das Produkt wird zur Sackgasse
Ektron war eines der verbreitetsten proprietären Enterprise-CMS im .NET-Bereich, eingesetzt von Unternehmen, die auf eine stabile, spezialisierte Plattform gesetzt hatten. Nachdem Accel-KKR zunächst Ektron und kurz darauf EPiServer übernommen hatte, wurden beide Unternehmen im Januar 2015 unter dem EPiServer-Namen fusioniert. Was folgte, war eine Migrationspflicht. Ektron-Kund*innen mussten auf eine neue Plattform wechseln, unabhängig davon, ob ihre Systeme dafür bereit waren. Der Anbieter existierte weiter. Das Produkt, auf das jahrelang gebaut worden war, nicht mehr.
Das ist kein Einzelfall, sondern ein Standardmuster in einem Markt, in dem Private-Equity-Gesellschaften Anbieter übernehmen, Produktlinien konsolidieren und Kund*innen vor vollendete Tatsachen stellen. Die Entscheidung, ob das eigene System weiterläuft, fällt dann an anderer Stelle.
02. Der Anbieter existiert, das Vertrauensverhältnis nicht mehr
Nicht jede Krise endet mit Insolvenz oder Übernahme. Manchmal zeigt sie sich in wiederholten Entlassungswellen, in instabilen Roadmaps und in Führungswechseln im Jahresrhythmus. Auf dem Papier ist der Anbieter dann intakt. In der Praxis fehlt die Stabilität, auf die eine Plattformentscheidung angewiesen ist.
Das lässt sich an mehreren etablierten Anbietern von Enterprise-CMS beobachten, deren Produktgenerationen so weit auseinanderliegen, dass eine Migration innerhalb derselben Produktfamilie faktisch einem Neuaufbau entspricht. Wer solche Signale ignoriert, weil der Vertragspartner noch existiert, entscheidet auf unvollständiger Grundlage.
03. Der Anbieter geht und hinterlässt eine Lücke
Digital River, ein globaler E-Commerce-Dienstleister mit Kunden wie Adobe und Lenovo, leitete im Januar 2025 seinen Abwicklungsprozess ein und meldete im Mai 2025 eine Chapter-7-Insolvenz an. Marin Software, ein etablierter Anbieter von digitalem Advertising-Management, folgte im Juli 2025 mit einer Chapter-11-Insolvenz. Beide Unternehmen hatten eine große Kundenbasis, Verträge und Integrationen, die niemand von heute auf morgen ersetzen kann.
Der Trend dahinter ist messbar. Nach Daten der Beteiligungsplattform Carta, ausgewertet von TechCrunch, stellten 2024 insgesamt 966 US-amerikanische Startups aus dem eigenen Kundenbestand den Betrieb ein, gegenüber 769 im Vorjahr. Enterprise-SaaS machte dabei 32 Prozent aller Schließungen aus und damit den größten Anteil aller Kategorien. Die Zahlen erfassen ausschließlich Carta-Kund*innen und zeichnen deshalb nur einen Teil des Marktes. Die Richtung ist trotzdem eindeutig.
Für Organisationen, die ihr digitales Ökosystem tief auf einer Plattform aufgebaut haben, bedeutet das ein konkretes Risiko. Workflows, Datenstrukturen, Integrationen und internes Wissen hängen dann an einem System, das niemand mehr aktiv wartet, und an einem Migrationsprojekt, für das weder Zeit noch Budget eingeplant war.
Warum Open Source strukturell anders antwortet
Bei einem proprietären System liegt die Kontrolle über Code, Roadmap, Lizenzmodell und Betrieb allein beim Anbieter. Fällt dieser Anbieter weg, sei es durch Insolvenz, Übernahme oder strategischen Pivot, ist die Zukunft der Software offen. Der Code ist nicht zugänglich, nicht übertragbar und nicht durch Dritte weiterentwickelbar. Sicherheitsupdates bleiben aus.
Wer auf der Plattform bleibt, steht früher oder später vor der Frage, wann migriert wird. Je länger diese Entscheidung aufgeschoben wird, desto mehr Innovationszyklen ziehen an der eigenen Organisation vorbei.
Bei einem Open-Source-System liegt der Code offen. Er kann eingesehen, geforkt, weiterentwickelt und betrieben werden, unabhängig davon, was mit dem ursprünglichen Dienstleister passiert. Das ist keine technische Randnotiz, sondern eine strukturelle Garantie, die proprietäre Systeme per Definition nicht geben können. Open Source bedeutet nicht, dass eine Software niemals das Ende ihres Lebenszyklus erreicht. Es bedeutet, dass diese Entscheidung nicht von einem einzelnen Unternehmen getroffen wird.
Was Open Source nicht garantiert
Open Source ist keine Versicherung gegen alles. Auch Open-Source-Projekte werden eingestellt, wenn die Community zu klein ist, das Projekt nicht mehr gepflegt wird oder der Markt sich verschiebt. Die entscheidenden Fragen sind deshalb, wie groß und wie aktiv die Community ist, wie lange das Projekt existiert und wer es trägt, eine einzelne Organisation oder ein breites Ökosystem.
Ein Open-Source-Projekt mit einer aktiven globalen Community ist strukturell stabiler als ein proprietäres SaaS-Produkt, das von einer Handvoll Entwickler*innen getragen wird, unabhängig davon, wie viel Risikokapital eingesammelt wurde.
Drupal ist dafür ein belastbares Beispiel. Das Content-Management-Framework wird seit dem ersten Release im Januar 2001 von einer globalen Community entwickelt, drupal.org verzeichnet über eine Million registrierte Community-Profile, und die Software läuft bei Regierungen, Universitäten und Großunternehmen auf allen Kontinenten. Diese Breite ist das Ergebnis einer Architekturentscheidung, nämlich offener Code, keine proprietären Abhängigkeiten und keine einzelne Organisation als Kontrollpunkt.
Der besondere Fall der Individualentwicklung
Software, die speziell für eine Organisation entwickelt wurde, etwa Portale, interne Werkzeuge oder branchenspezifische Anwendungen, trägt per Definition kein Community-Netzwerk. Wenn das entwickelnde Team wegfällt, bleibt im schlechten Fall eine Blackbox.
Die Antwort liegt nicht im Verzicht auf Individualentwicklung, sondern in der Art, wie sie gebaut wird. Code, der dokumentiert und modular auf offenen Standards aufsetzt, kann von einem anderen Team übernommen werden. Code mit proprietären Frameworks, undokumentierten Abhängigkeiten und ohne Testabdeckung kann es nicht. Der Unterschied zwischen wartbarer und nicht wartbarer Individualentwicklung ist keine Frage der Technologie, sondern eine Frage der Haltung, mit der gebaut wird.
Der Ausstieg ist eine Governance-Frage, nicht nur eine Lizenzfrage
Hier liegt der Punkt, der in den meisten Diskussionen über Lock-in fehlt. Offener Code ist die notwendige Bedingung für Handlungsfähigkeit, aber nicht die hinreichende. Organisationen mit offenen Systemen stehen regelmäßig genauso fest, weil niemand benennen kann, welches System welchem Ziel dient, wer über Änderungen entscheidet, welche Daten in welcher Struktur wo liegen und nach welchen Standards gebaut wird.
Wer diese Fragen beantworten kann, hat einen Ausstiegspfad, auch aus einem proprietären System. Wer sie nicht beantworten kann, bleibt gebunden, selbst wenn der Quellcode frei verfügbar ist. Deshalb beginnt die Arbeit an der Unabhängigkeit nicht bei der Technologiewahl, sondern bei Zielen, Prozessen und Verantwortlichkeiten. Die Technologie folgt daraus.
Was das für Verlage und Medienhäuser bedeutet
In Verlagen und Medienhäusern trifft dieses Risiko auf besonders lange Systemlebenszyklen. Redaktions-, Abo-, Shop- und Auslieferungssysteme sind über Jahre miteinander verflochten, und jede Migration berührt laufende Produktion. Gleichzeitig steht ein konkreter Anlass im Raum, denn der Support für Drupal 7 endete im Januar 2025, und Plattformen ohne Sicherheitsupdates sind für Häuser mit Bezahlinhalten und Nutzerdaten keine tragfähige Option.
Factorial arbeitet in diesem Umfeld unter anderem für C.H. Beck, dpa, die Verlagsgruppe Oetinger und RTL Publishing. Was sich in diesen Projekten zeigt, ist immer dasselbe Muster. Die technische Migration ist die kleinere Aufgabe. Die größere Aufgabe besteht darin, vorher zu klären, welche Systeme welchem Ziel dienen und wer worüber entscheidet.
Woran Sie einen übergabefähigen Partner erkennen
Das Anbieterrisiko gilt nicht nur für Plattformen, sondern auch für Dienstleister. Prüfbar ist es an drei Punkten. Läuft das System auf einer Open-Source-Plattform mit eigener Community. Ist die Individualentwicklung dokumentiert, modular und getestet. Liegen Repositories, Betrieb und Zugänge bei Ihnen. Sind diese drei Punkte erfüllt, kann ein anderes Team übernehmen, ohne neu zu bauen.
Genau so arbeiten wir. Übergabefähigkeit ist bei uns eine Anforderung an den Code und keine Zugabe am Projektende, und sie zeigt sich in jeder Architekturentscheidung, in jedem Code-Review und in jeder Plattformempfehlung.
Der nächste Schritt
Für die eigene Systemlandschaft lässt sich das in einem halben Tag klären. Genau das machen wir im Governance Quick Check, an dessen Ende eine Landkarte Ihrer digitalen Systeme steht, samt der drei bis fünf Stellen, an denen Abhängigkeit heute am teuersten wird.
Was wäre Ihr erster Schritt, wenn die Nachricht morgen kommt?
