# Exit-Strategie: So vermeiden Sie den Lock-in, bevor er entsteht

> Der beste Zeitpunkt, über den Ausstieg nachzudenken, ist vor dem Einstieg. Ein Leitfaden zu offenen Formaten, Exporttests, Vertragsklauseln, den Wechselrechten des EU Data Act und Architekturentscheidungen – mit Checkliste.

- Rubrik: Souveräne Software
- Format: Leitfaden
- Autor: Redaktion Umbrecher (umbrecher, https://umbrecher.com/ueber)
- Veröffentlicht: 2026-09-17
- Kanonische URL: https://umbrecher.com/artikel/exit-strategie-gegen-lock-in

## Das Wichtigste in Kürze

- Lock-in (Anbieterbindung) liegt vor, wenn die Kosten eines Wechsels die Entscheidung faktisch vorwegnehmen – betroffen sind Daten, Logik, Schnittstellen, Wissen und Verträge.
- Ein Datenexport sollte mindestens einmal jährlich und nach größeren Updates aus dem Produktivsystem getestet werden, denn ein nie getesteter Export ist nur eine Annahme.
- Der EU Data Act gilt seit dem 12. September 2025 und verlangt in Cloud-Verträgen unter anderem eine Kündigungsfrist von höchstens zwei Monaten und einen Übergang von höchstens 30 Kalendertagen.
- Ab dem 12. Januar 2027 sind Wechselentgelte von Cloud-Anbietern nach dem EU Data Act grundsätzlich verboten.
- Auch Open-Source-Software braucht einen Exit-Plan, weil von einzelnen Unternehmen getragene Projekte wie Redis ihre Lizenz ändern können.

Eine Exit-Strategie legt fest, wie ein Unternehmen eine Software oder einen Anbieter wieder verlassen kann – über offene Formate, getestete Exporte, Vertragsklauseln und eine austauschbare Architektur –, bevor Lock-in den Wechsel faktisch unmöglich macht.

Lock-in entsteht selten durch eine einzige falsche Entscheidung. Er wächst schleichend: hier eine praktische Spezialfunktion, dort eine proprietäre Schnittstelle, dazu Jahre an Daten in einem Format, das nur ein Hersteller vollständig versteht. Irgendwann ist der Wechsel so teuer, dass er praktisch ausgeschlossen ist – und der Anbieter weiß das.

Eine Exit-Strategie ist deshalb kein Misstrauensvotum gegen den aktuellen Anbieter, sondern gewöhnliches Risikomanagement. Dieser Leitfaden zeigt, an welchen Stellen Sie ansetzen können.

## Was ist Lock-in?

Von Lock-in (Anbieterbindung) spricht man, wenn die Kosten eines Wechsels so hoch sind, dass sie die Entscheidung faktisch vorwegnehmen. Diese Kosten haben mehrere Schichten:

- **Daten:** Lassen sie sich vollständig, mit allen Beziehungen und Metadaten, exportieren?
- **Logik:** Stecken Geschäftsregeln, Workflows oder Automatisierungen in herstellerspezifischen Werkzeugen?
- **Schnittstellen:** Hängen andere Systeme an proprietären APIs?
- **Wissen:** Können Ihre Leute nur dieses eine Produkt bedienen?
- **Verträge:** Laufzeiten, Mindestabnahmen, Kündigungsfristen, Rabatte, die an Bindung geknüpft sind.

Eine gute Exit-Strategie adressiert alle fünf.

## 1. Offene Formate und Standards bevorzugen

Je offener das Format, desto mehr Programme können es lesen. Bei Dokumenten ist das etwa das OpenDocument-Format (ODF), bei Kalendern und Kontakten iCalendar, CalDAV und CardDAV, bei E-Mail IMAP, bei Identitäten SAML oder OpenID Connect, bei Datenbanken SQL mit dokumentiertem Schema, bei Infrastruktur deklarative Beschreibungen wie Container-Images und Konfigurationsdateien.

Fragen Sie bei jeder Anschaffung: **In welchem Format liegen unsere Daten intern, und in welchem bekommen wir sie heraus?** Ein „Export als PDF“ ist kein Export, sondern ein Ausdruck.

## 2. Den Datenexport testen – regelmäßig

Viele Verträge versprechen eine Exportmöglichkeit. Was sie wert ist, zeigt erst der Versuch. Ein sinnvoller Exporttest:

1. Vollständigen Export aus dem Produktivsystem anstoßen – nicht aus einer Demo-Umgebung.
2. Prüfen, ob **alle** Datenkategorien enthalten sind: Anhänge, Historie, Kommentare, Berechtigungen, Metadaten.
3. Den Export in ein zweites System oder zumindest in ein neutrales Werkzeug (Datenbank, Tabellenkalkulation) laden.
4. Stichprobenartig mit dem Original vergleichen.
5. Dauer und Aufwand dokumentieren.

Wiederholen Sie das mindestens einmal jährlich und nach größeren Updates. Ein Export, der nie getestet wurde, ist eine Annahme.

## 3. Ausstieg vertraglich regeln

Der Vertrag ist der Ort, an dem Sie heute die Bedingungen für morgen festlegen. Wichtige Punkte:

- **Datenrückgabe:** Welche Daten, in welchem Format, innerhalb welcher Frist, zu welchen Kosten?
- **Unterstützung beim Wechsel:** Verpflichtet sich der Anbieter, an der Migration mitzuwirken?
- **Löschung:** Wann und wie werden die Daten nach dem Ausstieg nachweisbar gelöscht?
- **Laufzeit und Kündigung:** Kurze Kündigungsfristen und keine automatischen langen Verlängerungen.
- **Preisänderungen:** Sonderkündigungsrecht bei erheblichen Preiserhöhungen oder Lizenzänderungen.
- **Escrow** (Hinterlegung des Quellcodes bei Dritten): Bei geschäftskritischer proprietärer Software kann eine Hinterlegung für den Fall der Insolvenz sinnvoll sein.

## 4. Die Wechselrechte des EU Data Act nutzen

Für Cloud- und andere Datenverarbeitungsdienste hat der EU Data Act (Verordnung (EU) 2023/2854) die Ausgangslage spürbar verbessert. Die Verordnung gilt seit dem 12. September 2025. Ihr Kapitel VI regelt den Wechsel zwischen Anbietern; Artikel 25 schreibt unter anderem vor, dass Verträge folgende Punkte enthalten müssen:

- eine **Kündigungsfrist** für die Einleitung des Wechsels von **höchstens zwei Monaten**,
- einen **Übergangszeitraum** von **höchstens 30 Kalendertagen**, in dem der Wechsel abgeschlossen sein soll – ist das technisch nicht machbar, muss der Anbieter dies binnen 14 Arbeitstagen begründen und einen alternativen Zeitraum von höchstens sieben Monaten vorschlagen,
- einen **Zeitraum zum Abruf der Daten** von **mindestens 30 Kalendertagen** nach Ende der Übergangsphase,
- eine **erschöpfende Aufstellung** der Daten- und Asset-Kategorien, die übertragen werden können.

Zu den Kosten regelt Artikel 29 einen Stufenplan: Bis einschließlich 11. Januar 2027 dürfen Anbieter nur noch reduzierte Wechselentgelte verlangen, die die unmittelbar mit dem Wechsel verbundenen Kosten nicht übersteigen. **Ab dem 12. Januar 2027 sind Wechselentgelte grundsätzlich verboten.**

Praktisch heißt das: Prüfen Sie bestehende Cloud-Verträge darauf, ob sie diese Punkte abbilden, und sprechen Sie Anbieter aktiv darauf an. Ausführlich behandelt das unser Beitrag [EU Data Act: Was der Cloud-Wechsel jetzt bedeutet](/artikel/eu-data-act-cloud-wechsel).

Wichtig: Der Data Act sichert den Prozess, nicht die technische Kompatibilität. Wenn Ihre Anwendungen tief in proprietäre Dienste eines Anbieters verwoben sind, hilft Ihnen auch die kürzeste Frist wenig. Deshalb bleibt die Architektur entscheidend.

## 5. Architektur auf Austauschbarkeit auslegen

Einige Grundsätze, die den Wechsel erleichtern:

- **Abstraktionsschichten:** Eigene Anwendungen sprechen mit einer internen Schnittstelle, nicht direkt mit der proprietären API eines Anbieters.
- **Standardisierte Laufzeitumgebungen:** Container und gängige Orchestrierung statt anbieterspezifischer Plattformdienste, wo es vertretbar ist.
- **Infrastruktur als Code:** Wenn Ihre Umgebung in Konfigurationsdateien beschrieben ist, lässt sie sich leichter anderswo aufbauen. Achten Sie dabei auch auf die Lizenz des Werkzeugs selbst – nach der Lizenzänderung bei Terraform 2023 entstand mit OpenTofu ein quelloffener Fork, der seit Januar 2024 stabil verfügbar ist.
- **Identitäten zentral und offen:** Anmeldung über einen eigenen Identitätsanbieter mit offenen Protokollen, nicht über das Konto eines einzelnen Anbieters.
- **Spezialfunktionen bewusst einsetzen:** Proprietäre Komfortfunktionen sind nicht verboten, sollten aber eine dokumentierte Entscheidung sein – mit einer Notiz, wie man sie im Ernstfall ersetzt.

## 6. Auch Open Source braucht einen Exit-Plan

Open-Source-Software senkt das Lock-in-Risiko deutlich, beseitigt es aber nicht. Mehrere bekannte Projekte, die von einem einzelnen Unternehmen getragen wurden, haben ihre Lizenz geändert – Redis etwa stellte im März 2024 ab Version 7.4 von der BSD-Lizenz auf ein Source-Available-Modell um. Die Nutzer früherer Versionen behielten ihre Rechte, und aus der Community entstanden Forks. Hintergründe beschreibt unser Erklärstück zu [Open-Source-Lizenzen](/artikel/open-source-lizenzen-fuer-entscheider). Die Lehre: Achten Sie darauf, ob ein Projekt von einer breiten Gemeinschaft oder einer neutralen Stiftung getragen wird – und wie sich die Herstellerfirma finanziert (siehe [Wie Open-Source-Firmen sich finanzieren](/artikel/wie-open-source-firmen-sich-finanzieren)).

## 7. Den Exit durchrechnen

Eine Exit-Strategie wird belastbar, wenn sie eine Zahl hat. Beispiel: Angenommen, ein Unternehmen schätzt für den Wechsel seines Dokumentenmanagements 40 Personentage interne Arbeit, 20 Personentage externe Unterstützung und zwei Monate Parallelbetrieb. Diese Größenordnung gehört in jede Gesamtkostenbetrachtung – wie das geht, zeigt [TCO ehrlich rechnen](/artikel/tco-ehrlich-rechnen). Unser [Kostenrechner](/werkzeuge/kostenrechner) hilft bei einer ersten Abschätzung.

## Checkliste: Exit-Fähigkeit prüfen

- [ ] Liste der geschäftskritischen Systeme und ihrer Anbieter liegt vor.
- [ ] Für jedes System ist dokumentiert, in welchem Format die Daten intern und beim Export vorliegen.
- [ ] Ein vollständiger Exporttest wurde in den letzten zwölf Monaten durchgeführt und dokumentiert.
- [ ] Verträge regeln Datenrückgabe, Formate, Fristen, Mitwirkung und Löschung.
- [ ] Cloud-Verträge wurden auf die Anforderungen des EU Data Act geprüft.
- [ ] Sonderkündigungsrechte bei Preis- oder Lizenzänderungen sind vereinbart.
- [ ] Mindestens eine realistische Alternative pro kritischem System ist benannt.
- [ ] Proprietäre Spezialfunktionen sind erfasst, inklusive Ersatzplan.
- [ ] Identitäten und Zugänge laufen über eine zentrale, offene Lösung.
- [ ] Der geschätzte Aufwand für einen Wechsel ist beziffert und in der Kostenplanung enthalten.
- [ ] Zuständigkeit für die Exit-Strategie ist festgelegt und wird jährlich überprüft.

## Nächste Schritte

Beginnen Sie klein: Wählen Sie das eine System, dessen Ausfall Ihr Geschäft am härtesten treffen würde, und führen Sie dafür in den nächsten vier Wochen einen echten Exporttest durch. Das Ergebnis sagt Ihnen mehr über Ihre Abhängigkeit als jede Strategiefolie. Danach folgen Vertragsprüfung und Architekturfragen. Was digitale Souveränität grundsätzlich ausmacht, beschreibt unser Erklärstück [Was digitale Souveränität bedeutet](/artikel/was-digitale-souveraenitaet-bedeutet).

Dieser Beitrag ersetzt keine Rechtsberatung.

## Häufige Fragen

### Was ist eine Exit-Strategie in der IT?

Eine Exit-Strategie legt schon vor dem Einstieg fest, wie ein Unternehmen ein System oder einen Anbieter wieder verlassen kann – sie ist gewöhnliches Risikomanagement, kein Misstrauensvotum. Sie setzt an fünf Stellen an: Daten, Logik, Schnittstellen, Wissen und Verträge. Zentrale Werkzeuge sind offene Formate, regelmäßige Exporttests, Vertragsklauseln zu Datenrückgabe und Löschung sowie eine Architektur, die Komponenten austauschbar hält.

### Welche Wechselrechte gibt der EU Data Act bei Cloud-Diensten?

Seit dem 12. September 2025 müssen Cloud-Verträge nach Artikel 25 des Data Act eine Kündigungsfrist von höchstens zwei Monaten, einen Übergangszeitraum von höchstens 30 Kalendertagen, mindestens 30 Kalendertage zum Datenabruf und eine erschöpfende Aufstellung der übertragbaren Daten enthalten. Ist der Übergang technisch nicht machbar, muss der Anbieter das begründen und kann einen Zeitraum von höchstens sieben Monaten vorschlagen. Im Einzelfall rechtlich prüfen lassen.

### Ab wann sind Wechselentgelte beim Cloud-Wechsel verboten?

Ab dem 12. Januar 2027. Bis einschließlich 11. Januar 2027 dürfen Anbieter nach Artikel 29 des EU Data Act nur reduzierte Wechselentgelte verlangen, die die unmittelbar mit dem Wechsel verbundenen Kosten nicht übersteigen. Der Data Act sichert allerdings den Prozess, nicht die technische Kompatibilität: Wer tief in proprietäre Dienste verwoben ist, profitiert von kurzen Fristen wenig. Im Einzelfall rechtlich prüfen lassen.

### Wie testet man einen Datenexport richtig?

Mit einem vollständigen Export aus dem Produktivsystem, nicht aus einer Demo-Umgebung. Danach prüfen Sie, ob alle Datenkategorien enthalten sind – Anhänge, Historie, Kommentare, Berechtigungen, Metadaten –, laden den Export in ein zweites System oder ein neutrales Werkzeug, vergleichen Stichproben mit dem Original und dokumentieren Dauer und Aufwand. Wiederholen Sie den Test mindestens einmal jährlich und nach größeren Updates.

### Schützt Open-Source-Software vor Lock-in?

Nur teilweise. Open-Source-Software senkt das Lock-in-Risiko deutlich, beseitigt es aber nicht. Redis etwa stellte im März 2024 ab Version 7.4 von der BSD-Lizenz auf ein Source-Available-Modell um; Nutzer früherer Versionen behielten ihre Rechte, und aus der Community entstanden Forks. Achten Sie deshalb darauf, ob ein Projekt von einer breiten Gemeinschaft oder einer neutralen Stiftung getragen wird und wie sich die Herstellerfirma finanziert.

## Quellen

1. [Verordnung (EU) 2023/2854 (Data Act) – EUR-Lex](https://eur-lex.europa.eu/eli/reg/2023/2854/oj)
2. [Data Act, Art. 25 – Vertragsbedingungen für den Wechsel (Springlex, konsolidierter Text)](https://www.springlex.eu/en/packages/data-act/data-act-regulation/article-25/)
3. [Data Act, Art. 29 – Schrittweise Abschaffung der Wechselentgelte (Springlex, konsolidierter Text)](https://www.springlex.eu/de/packages/data-act/data-act-regulation/article-29/)
4. [Bundesnetzagentur – Glossar Data Act: Wechselentgelt](https://www.bundesnetzagentur.de/SharedDocs/A_Z_Glossar_DataAct_ENG/S/switching-charge.html)
5. [Redis – Redis Adopts Dual Source-Available Licensing (20.03.2024)](https://redis.io/blog/redis-adopts-dual-source-available-licensing/)
6. [OpenTofu – OpenTofu is going GA (10.01.2024)](https://opentofu.org/blog/opentofu-is-going-ga/)