Wie ein fairer Plattform-Exit-Export aussieht
Ein Leitfaden für Wechselfähigkeit, Datenportabilität und digitale Souveränität — als Prüfraster für jeden Plattformanbieter. Auch für uns.
Woran Plattformwechsel wirklich scheitern
Ein Plattformwechsel scheitert selten an der reinen Datenmenge. Er scheitert daran, dass Daten zwar formal „herausgegeben" werden, operativ aber kaum sinnvoll weiterverarbeitet werden können. Tausende Excel-Dateien, verstreute PDFs und fehlende Feldlogiken erzeugen Übergabekosten, Projektrisiken und faktische Abhängigkeit.
Ein fairer Exit beginnt deshalb nicht mit der Kündigung, sondern mit einer klaren Antwort auf eine einfache Frage:
In welchem Zustand bekomme ich meine Daten zurück?
Tausende Einzeldateien — ohne Struktur, ohne Dokumentation, ohne Zusammenhang.
Ein konsistentes, dokumentiertes XML-Paket — direkt maschinell weiterverarbeitbar.
Was ein brauchbarer Exit-Export leisten muss
Ein Exit-Export ist nur dann praxistauglich, wenn er nicht nur Daten liefert, sondern ihre technische und fachliche Wiederverwendbarkeit sicherstellt. Ein belastbarer Export umfasst mindestens:
Schlechter vs. guter Export
| Kriterium | Schlechter Exit-Export | Guter Exit-Export |
|---|---|---|
| Datenformat | Viele Excel-Dateien, PDFs, Einzeldateien | Ein konsistentes XML-Paket mit klarer Struktur |
| Verarbeitbarkeit | Hoher manueller Aufbereitungsaufwand | Direkte technische Weiterverarbeitung möglich |
| Dokumentation | Keine oder nur informelle Erläuterungen | Vollständige Feld-, Struktur- und Relationenbeschreibung |
| Nachvollziehbarkeit | Unklare Zusammenhänge zwischen Dateien | Eindeutige Zuordnung zwischen Objekten und Beständen |
| Migrationsfähigkeit | Hoher Abstimmungs- und Klärungsbedarf | Import in Folgeplattform oder Datenprojekt planbar |
| Governance | Formale Rückgabe, aber geringe Nutzbarkeit | Rückgabe mit echter operativer Wechselfähigkeit |
Sechs Bausteine eines fairen XML-Exit-Pakets
Ein sauberer und umfassend dokumentierter XML-Export besteht aus fachlicher und technischer Sicht aus mindestens sechs Bausteinen.
Nutzbare Datenstruktur
- XML als Hauptformat für den vollständigen Datenbestand
- Klare Objektlogik: Arbeitgeber, Verträge, versicherte Personen, Vorgänge, Status, Portale, Dokumentreferenzen
- Stabile IDs und eindeutige Relationen zwischen den Objekten
Schema und Felddefinitionen
- XSD oder vergleichbare formale Schemabeschreibung
- Datenfeldkatalog mit Feldname, fachlicher Bedeutung, Datentyp, Pflicht-/Kannfeld, Wertebereich und Beispielwert
- Dokumentation von Enumerationen, Statuscodes und Sonderfällen
Paketlogik
- Definierte Ordner- und Dateistruktur, eindeutige Benennungskonventionen
- Versionskennzeichen für Exportstand und Datenmodell
- Prüfsummen oder andere Integritätsmerkmale für zentrale Dateien
Dokumentenbezug
- Dokumente nicht lose, sondern referenziert und zuordenbar
- Klare Verknüpfung zwischen XML-Datensatz und zugehörigen PDF- oder Anhangsdateien
- Trennung zwischen strukturierten Fachdaten und Belegdokumenten
Importfähigkeit
- Mindestens ein Beispielexport
- Mapping-Hinweise für Drittsysteme oder Folgeplattformen
- Dokumentierte Regeln für Zeichensätze, Datumsformate, Nummernkreise und Pflichtfelder
Betriebsfähige Übergabe
- Benannter technischer Ansprechpartner für Rückfragen
- Definierter Übergabezeitpunkt und Exportstichtag
- Dokumentation des Exports als Bestandteil des Exit-Prozesses, nicht als Kulanzleistung
Der Praxistest für Entscheider
Vor der Unterschrift sollten drei Fragen gestellt werden:
Kann der Anbieter heute einen vollständigen, dokumentierten Testexport zeigen?
Ist das Datenformat maschinell nutzbar oder nur manuell lesbar?
Reicht die Dokumentation aus, damit ein Dritter den Bestand ohne Rückengineering übernehmen kann?
Wenn eine dieser Fragen offen bleibt, ist die Exit-Fähigkeit nicht gesichert.
Der regulatorische Maßstab: DORA
Für regulierte Finanzunternehmen verlangt Art. 30 Abs. 2 lit. d DORA vertragliche Bestimmungen zu Zugang, Wiederherstellung und Rückgabe personenbezogener und nicht personenbezogener Daten in einem leicht zugänglichen Format — unter anderem bei Vertragsbeendigung. Unabhängig von einer unmittelbaren DORA-Pflicht ist genau das ein sinnvoller Maßstab für faire Plattformverträge.
[1] Digital Operational Resilience Act (DORA), Artikel 30 — digital-operational-resilience-act.com/Article_30.html
[2] BaFin, Aufsichtsmitteilung Umsetzungshinweise DORA — bafin.de
[3] Digital Operational Resilience Act (DORA), Artikel 2 — digital-operational-resilience-act.com/Article_2.html
Stellen Sie uns die drei Fragen
Wir zeigen Ihnen einen vollständigen, dokumentierten Testexport — im ersten Gespräch, nicht nach der Unterschrift. Dieselben offenen Schnittstellen gelten bei uns nach innen wie nach außen.