Uni Leipzig, 4. November 2026. Wer über ERP-Software spricht, landet schnell bei Tabellen, Budgets und ziemlich langen Einführungsprojekten. Dahinter steckt aber eine handfeste Frage: Was passiert, wenn ein Unternehmen sein System wechseln muss – oder der Anbieter plötzlich nicht mehr weitermacht?

Golem.de hat diese Frage in der Reihe „Chefs von Devs“ aufgegriffen. Das Interview mit Markus Bätz trägt den Titel „Wie Open Source vor dem Vendor-Lock-in schützt“. Im Mittelpunkt steht eine ERP-Software, die beinahe verloren ging und anschließend als gemeinschaftlich getragenes Projekt weitergeführt wurde. Welche Software genau gemeint ist, welche Organisation beteiligt war, unter welcher Lizenz sie steht, wann die entscheidenden Schritte stattfanden und welche Finanzzahlen dahinterstehen, ist in der frei zugänglichen Beschreibung allerdings nicht bekannt. Auch wörtliche Aussagen von Bätz liegen über die Kurzbeschreibung hinaus nicht vor.

Wenn der Anbieter verschwindet

ERP-Systeme verbinden typischerweise Finanzbuchhaltung, Lager, Einkauf und Produktion. Ein Wechsel ist deshalb kein simples „neue Oberfläche installieren“. Prozesswissen, Stammdaten, Anpassungen und Zusatzmodule müssen übertragen werden. Dazu kommen Belege und Historien, die vollständig und prüfbar erhalten bleiben sollen. Schon der Gedanke daran macht vielen Verantwortlichen vermutlich keinen besonders ruhigen Abend.

Der sogenannte Vendor-Lock-in sitzt auf mehreren Ebenen. Technisch können proprietäre Formate und Schnittstellen den Ausstieg erschweren. Verträge binden über Laufzeiten und Kündigungsfristen. Wirtschaftlich schlagen Schulungen, Anpassungen und Zusatzmodule zu Buche. Organisatorisch hängt viel an Mitarbeiterinnen und Mitarbeitern, die das System und seine Eigenheiten kennen.

Bei proprietärer Software liegt die Weiterentwicklung zudem bei einem einzelnen Anbieter. Stellt er Betrieb oder Entwicklung ein, fehlen häufig Quellcode und Rechte für den eigenständigen Weiterbetrieb. Ein Unternehmen steht dann nicht bloß vor einer neuen Softwareauswahl, sondern vor einer möglichen Notoperation am laufenden Geschäft.

Hier könnte Ihr Advertorial stehen
Ein Advertorial bietet Unternehmen die Möglichkeit, ihre Botschaft direkt im redaktionellen Umfeld zu platzieren

Open Source kann diese Abhängigkeit verringern. Der Quellcode lässt sich prüfen, sichern und selbst bauen. Lizenzen erlauben meist Änderungen und Weitergabe. Die Software kann im eigenen Rechenzentrum, bei Hostern oder in verschiedenen Clouds laufen. Offene Datenformate und verfügbarer Quellcode helfen außerdem dabei, ERP-Daten langfristig lesbar zu halten. Sicherheitslücken können Unternehmen auch ohne den ursprünglichen Anbieter beheben – vorausgesetzt, Code und Fachwissen sind vorhanden.

Wichtig ist der kleine, aber entscheidende Zusatz: Ob eine Weiterführung wirklich möglich ist, hängt von der konkreten Lizenz ab. Für eine schnelle Übernahme nennt der Artikel drei Voraussetzungen: eine vollständige Kopie des Codes samt Build-Anleitung, mehrere Personen oder Organisationen mit Fachwissen und eine Plattform, auf der Änderungen koordiniert werden können.

Gemeinschaft ist kein Selbstläufer

Open Source garantiert nicht automatisch, dass ein Projekt überlebt. Kernentwickler können gehen, Sponsoren sich zurückziehen, Unternehmen neue Prioritäten setzen. Als weiteres Beispiel nennt der Artikel den Rückzug von Cloudflare aus der Unterstützung der Deno-Runtime.

Warnsignale sind weniger Beiträge, ausbleibende Sicherheitsupdates und unbeantwortete Fehlerberichte. Anwender sollten ihre Abhängigkeiten dokumentieren und frühzeitig Kontakt zu anderen Nutzern aufnehmen. Das klingt trocken, ist aber im Ernstfall Gold wert.

„Gemeinschaftlich getragen“ kann organisatorisch vieles bedeuten: Mehrere Unternehmen stellen Entwickler ab, ein Verein verwaltet Spenden oder eine Stiftung hält Marke und Projekt. Für die konkrete ERP-Software aus dem Interview ist die Organisationsform nicht bekannt. Offen bleiben damit auch zentrale Governance-Fragen: Wer darf Änderungen in den Hauptzweig übernehmen? Wer finanziert die Wartung? Wem gehören Name und Domain?

Ein gemeinschaftliches Projekt kann unter dem Trittbrettfahrerproblem leiden. Viele profitieren, aber nur wenige zahlen oder tragen bei. Denkbare Finanzierungsmodelle sind Mitgliedsbeiträge, Wartungsverträge und verbindliche Beiträge von Unternehmen. Als positives Beispiel aus einem anderen Bereich nennt der Artikel Home Assistant, das von einer breiten Gemeinschaft getragen wird.

Trägermodell Einordnung des Risikos
Proprietäre Software Hohes Lock-in-Risiko
Open Source eines einzelnen Herstellers Mittleres Risiko
Stiftungsgetragenes Projekt Niedriges bis mittleres Risiko
Gemeinschaftlich getragenes Projekt Niedriges Risiko, solange genügend Beitragende bleiben
Fork nach Rückzug eines Herstellers Niedriges bis mittleres Risiko; die Aufbauphase ist anfällig

Auch eine Open-Core-Richtlinie in einem öffentlichen Repository kann zeigen, wo der freie und wo der kommerzielle Teil eines Angebots beginnt. Lizenzstreitigkeiten und Rückzüge von Herstellern haben in den vergangenen Jahren mehrfach zu Abspaltungen von Open-Source-Projekten geführt. Freie Lizenzen schützen praktisch nur dann vor Lock-in, wenn Unternehmen den Code, die Lizenz und ihr eigenes Know-how tatsächlich nutzen.

ERP zwischen SAP, Cloud und Eigenbau

Der Blick auf Alternativen zu SAP erweitert die Debatte. Monolithische ERP-Systeme zentralisieren Finanzen, Personalwesen, Lieferkette und operative Abläufe. SaaS-Geschäftsmodelle, Digitalisierung und der Wunsch nach mehr Agilität verstärken die Kritik an solchen Systemen. Gesucht werden vor allem geringere Kosten, kürzere Einführungszeiten, höhere Nutzerakzeptanz und eine schnellere Integration neuer Funktionen.

Bei SAP werden Lizenzen meist nach Nutzern und Modulen berechnet. Laut dem genannten Artikel können sie bis zu 30 Prozent des IT-Jahresbudgets großer Konzerne ausmachen. Wartung, Support und Beratung kommen hinzu; über fünf bis zehn Jahre können die Gesamtbetriebskosten die konkurrierender ERP-Systeme übersteigen. Zertifizierte Integratoren, Parametrierung, Tests und Schulungen binden dabei Geld und Personal. In manchen Projekten steigen die Budgets laut Artikel um 20 bis 40 Prozent, weil die Komplexität der Einführung unterschätzt wurde. Zusatzlizenzen für Analytics, Cloud oder Mobility machen die Planung nicht gerade übersichtlicher.

Eine Standard-SAP-Einführung dauert je nach Umfang und Prozessreife typischerweise sechs bis 24 Monate. Analyse, Konfiguration, Integrationstests, Schulungen und Abnahmen ziehen sich bei individuellen Workflows länger. Zusätzliche Entwicklungen, etwa für KI oder Automatisierung, können den Zeitraum weiter ausdehnen. Vorgegebene Workflows decken allgemeine Anforderungen ab, passen aber nicht immer zu branchenspezifischen oder lokalen Abläufen. Individueller Code erhöht die Komplexität und kann spätere Updates erschweren. Die Abhängigkeit von Spezialcode und zertifizierten Integratoren verstärkt den Vendor-Lock-in.

Moderne Cloud-ERP-Lösungen wie Microsoft Dynamics 365, Oracle Fusion Cloud und Workday arbeiten nach dem SaaS-Modell. Gebühren fallen abonnementbasiert nach Nutzerzahl und Modulen an, während Anbieter Updates und Infrastruktur übernehmen. Integrierte Analytics-, Reporting- und Kollaborationsfunktionen können den Eigenbetrieb reduzieren. Tiefgreifende Individualisierungen bleiben allerdings häufig eingeschränkt. Wer eigene Workflows an Anbieter-APIs und deren Entwicklungsvorgaben hängt, tauscht eine Abhängigkeit womöglich nur gegen eine andere aus.

Open-Source- und modulare Systeme wie Odoo, ERPNext und Dolibarr bieten einen lizenzkostenfreien ERP-Kern mit Modulen für Finanzen, CRM, Einkauf, Lager und Personalwesen. Der Quellcode erlaubt Anpassungen an Unternehmensgröße und wechselnde Anforderungen; Updates lassen sich stärker selbst steuern als bei festen Anbieter-Release-Zyklen. Dafür braucht es internes oder externes Know-how für Wartung, Updates und Sicherheitspatches. Laut Artikel senkte ein Industrieunternehmen durch die teilweise Ablösung von SAP mit einem Open-Source-ERP seine Gesamtbetriebskosten innerhalb von drei Jahren um 40 Prozent.

Daneben stehen Low-Code-Plattformen wie Mendix und OutSystems. Sie ermöglichen individuelle Anwendungen und Erweiterungen, ohne ein komplettes ERP neu zu entwickeln, und bieten Konnektoren zu bestehenden Systemen. Beim Best-of-Breed-Ansatz wird für jede Aufgabe eine spezialisierte Anwendung gewählt – etwa ein WMS für Lager, ein TMS für Transport oder ein HRIS für Personal. Eine Integrationsschicht beziehungsweise iPaaS verbindet die Systeme. Ein zentrales Finanz-ERP kann so mit Speziallösungen für Einkauf oder Logistik zusammenspielen.

Modell Stärken und Grenzen
Standard-SaaS-ERP Schnelle Budgettransparenz und kurze Einführung; laufende Gebühren sowie mögliche Zusatzkosten für Erweiterungen und API-Aufrufe</