Datenhoheit
Wie abhängig ist Ihr Unternehmen von Softwareanbietern?
In einem Kundenprojekt sollte ein über Jahre genutztes System abgelöst werden. Auf den ersten Blick war die Ausgangslage komfortabel: Der Anbieter bot einen Datenexport an, die Geschäftsführung hatte Zugriff auf sämtliche Datensätze und im Vertrag stand ausdrücklich, dass die Daten dem Kunden gehören. Trotzdem dauerte es Monate, bis die wichtigsten Informationen im neuen System brauchbar ankamen.
Der Export enthielt zwar Kunden, Vorgänge und Dokumente, aber viele Beziehungen zwischen diesen Daten fehlten. Interne Statuswerte waren nur als Nummern gespeichert. Dateianhänge lagen ohne verständliche Zuordnung in separaten Verzeichnissen. Historische Bearbeitungsschritte und Berechtigungen ließen sich gar nicht übertragen. Formal waren die Daten vorhanden. Praktisch konnte das Unternehmen mit einem großen Teil davon zunächst wenig anfangen.
Solche Situationen erleben wir häufig. Unternehmen sprechen von Datenhoheit, wenn sie einen Vertrag, ein Administratorkonto und eine Exportfunktion besitzen. Technisch reicht das nicht. Wirkliche Datenhoheit zeigt sich erst dann, wenn ein Unternehmen seine Informationen unabhängig vom bisherigen Anbieter verstehen, sichern, verarbeiten und in einem anderen System weiterverwenden kann.
Diese Unterscheidung wird mit wachsender Digitalisierung wichtiger. Kundendaten liegen im CRM, Dokumente in einer Cloud-Plattform, Projekte in einem SaaS-Werkzeug und operative Abläufe in einer Branchenlösung. Jedes System löst ein konkretes Problem. Über die Jahre entsteht daraus jedoch eine Infrastruktur, deren Abhängigkeiten kaum jemand vollständig überblickt. Solange alle Dienste funktionieren, fällt das selten auf. Sichtbar wird es bei einem Anbieterwechsel, einer Preiserhöhung, einer Übernahme oder der Einstellung eines Produkts.
Eigentum an Daten ist noch keine technische Kontrolle
In Verträgen findet sich häufig eine beruhigende Formulierung: Die eingegebenen Daten bleiben Eigentum des Kunden. Juristisch kann das wichtig sein. Für den praktischen Betrieb beantwortet der Satz aber nur einen kleinen Teil der relevanten Fragen. Er sagt nicht, in welchem Format Daten bereitgestellt werden, welche Informationen der Export umfasst oder wie viel Aufwand nötig ist, um sie in einem anderen System wieder nutzbar zu machen.
Eine CSV-Datei mit Kundennamen und E-Mail-Adressen lässt sich leicht öffnen. Bei einer gewachsenen Geschäftsanwendung sieht die Lage anders aus. Dort bestehen Datensätze aus Beziehungen, Statusmodellen, Kommentaren, Anhängen, Benutzerrechten, Protokollen und individuellen Feldern. Fehlen beim Export die Verknüpfungen oder ihre Dokumentation, bleibt ein Bestand aus Einzelteilen zurück.
Aus technischer Sicht gehören deshalb mindestens vier Fähigkeiten zur Datenhoheit. Das Unternehmen muss Daten vollständig erhalten, ihre Struktur verstehen, ihre Integrität prüfen und sie in einem anderen Kontext verwenden können. Wenn nur einer dieser Punkte fehlt, entsteht beim Wechsel erheblicher manueller Aufwand.
Besonders kritisch sind proprietäre Formate. Sie können für den laufenden Betrieb sinnvoll sein, weil sie spezielle Funktionen ermöglichen. Ohne dokumentierte Schnittstelle oder Konverter binden sie Daten jedoch an eine bestimmte Software. Eine Datei zu besitzen hilft wenig, wenn nur das gekündigte Programm sie korrekt lesen kann.
Der beste Test beginnt mit einer einfachen Frage
Bei der Auswahl einer Software wird viel über Funktionen gesprochen. Geprüft werden vor allem Funktionen für Angebote, Automatisierung und Auswertungen. Die Bedingungen für einen späteren Ausstieg kommen meist am Ende oder gar nicht zur Sprache. Dabei sollte schon vor der Auswahl feststehen, was das Unternehmen bei einer Vertragsbeendigung tatsächlich erhält.
Eine belastbare Antwort nennt mehr als das Wort Export. Sie beschreibt Formate, Datenkategorien, Dateianhänge, Metadaten, Beziehungen, Fristen und technische Zugangswege. Außerdem sollte klar sein, ob der Export selbstständig ausgeführt werden kann oder kostenpflichtige Unterstützung des Anbieters benötigt.
Wir empfehlen bei geschäftskritischen Systemen, einen Testexport nicht erst vor der Kündigung durchzuführen. Er gehört in die Auswahlphase und später in regelmäßige Betriebsprüfungen. Ein kleiner Beispieldatensatz zeigt schnell, ob Umlaute, Datumswerte, individuelle Felder und Zuordnungen sauber übertragen werden. Bei einem reinen Verkaufsgespräch bleiben solche Details leicht abstrakt.
Ein guter Test endet nicht mit dem erfolgreichen Download. Die Dateien müssen auf einem unabhängigen System geöffnet und geprüft werden. Geprüft werden Anzahl und Vollständigkeit der Datensätze, Summen, Zeiträume und die Zuordnung der Dokumente. Fachanwender sollten außerdem einen Kundenfall nachvollziehen können, ohne die alte Oberfläche zu öffnen. Erst dieser Praxistest zeigt den tatsächlichen Wert des Exports.
Vollständig bedeutet mehr als Stammdaten
Viele Exporte konzentrieren sich auf die sichtbaren Stammdaten. Das sind Kunden, Produkte, Ansprechpartner oder Projekte. Für die Fortführung eines Geschäftsprozesses reichen diese Informationen oft nicht aus. Wichtig sind auch Bewegungsdaten und der Kontext, in dem sie entstanden sind.
Ein CRM enthält beispielsweise Gesprächsnotizen, Aufgaben, Zuständigkeiten, Einwilligungen, E-Mail-Verläufe und Beziehungen zwischen Kontakten und Unternehmen. Eine Projektplattform speichert Kommentare, Freigaben, Versionen und Abhängigkeiten. In einem Ticketsystem sind Reaktionszeiten, Statuswechsel und interne Hinweise relevant. Werden nur die Haupttabellen exportiert, verschwindet ein Teil der Unternehmensgeschichte.
Gerade bei bestehenden Anwendungen zeigt sich zudem, dass individuelle Felder eine größere Rolle spielen als erwartet. Sie wurden angelegt, weil der Standardprozess nicht alle Anforderungen abbildete. Bei einer Migration müssen nicht nur ihre Werte übernommen werden. Das neue System muss auch verstehen, was diese Felder bedeuten und wie sie verwendet wurden.
Ein Feld mit dem Namen „Kategorie 2“ ist ohne Dokumentation kaum interpretierbar. Dasselbe gilt für Statuscodes wie 4, 7 oder 12. Solange die alte Anwendung die passende Beschriftung anzeigt, fällt das nicht auf. Im Rohdatenexport fehlt dieser Übersetzungsschritt häufig. Datenhoheit braucht daher auch Wissen über das Datenmodell.
Metadaten entscheiden über die spätere Nutzbarkeit
Metadaten wirken im Tagesgeschäft unscheinbar. Bei einer Migration entscheiden sie oft darüber, ob Informationen korrekt eingeordnet werden können. Erstellungszeit, letzte Änderung, Autor, Dateityp, Version und Zugriffsrechte gehören dazu. Ohne diese Angaben lassen sich Dokumente zwar öffnen, aber nicht immer verlässlich bewerten.
Ein Beispiel sind Vertragsunterlagen. Liegen mehrere Fassungen als Dateien vor, muss erkennbar bleiben, welche Version gültig war und wer sie freigegeben hat. Werden beim Export sämtliche Dateien mit dem aktuellen Kopierdatum versehen, geht ein wichtiger Teil der Nachvollziehbarkeit verloren.
Auch Berechtigungen sind Daten. Ein neues System sollte nicht automatisch jedem Mitarbeiter Zugriff auf sämtliche übernommenen Inhalte geben. Dafür müssen Rollen, Gruppen und individuelle Freigaben entweder exportiert oder vor der Migration nachvollziehbar dokumentiert werden. Dieser Bereich wird bei frühen Kostenschätzungen gern vergessen und taucht später als aufwendige Handarbeit wieder auf.
Aus unserer Erfahrung lohnt sich eine Trennung zwischen Daten, die für den operativen Neustart benötigt werden, und Informationen, die aus Nachweis- oder Aufbewahrungsgründen erhalten bleiben müssen. Nicht jeder historische Eintrag muss im neuen System aktiv bearbeitbar sein. Ein revisionssicheres, gut durchsuchbares Archiv kann für ältere Bestände die bessere Lösung sein.
Eine API allein verhindert keinen Vendor-Lock-in
Anbieter verweisen bei Fragen zur Offenheit gern auf ihre API. Eine dokumentierte Schnittstelle ist grundsätzlich positiv. Sie ermöglicht automatisierte Exporte, Integrationen und laufende Datensicherungen. Trotzdem ist das Vorhandensein einer API noch kein Beleg für Unabhängigkeit.
Entscheidend sind Umfang und Nutzungsbedingungen. Manche Schnittstellen liefern nur einen Teil der Daten. Andere begrenzen Anfragen so stark, dass ein vollständiger Export Wochen dauern würde. Dateianhänge benötigen separate Aufrufe, historische Versionen fehlen oder individuelle Felder sind nur über Sonderwege erreichbar. Auch Kosten pro Anfrage können einen großen Export verteuern.
Hinzu kommt die Lebensdauer einer API-Version. Wenn Schnittstellen regelmäßig geändert werden, muss die eigene Integration gepflegt werden. Eine Anwendung, die Daten theoretisch abrufen könnte, aber seit zwei Jahren nicht mehr mit der aktuellen API funktioniert, bietet keine verlässliche Exit-Strategie.
Für die nächste Ausgabe unseres Blogs behandeln wir API-Abhängigkeiten ausführlich. Im Zusammenhang mit Datenhoheit reicht zunächst eine klare Prüfung: Die Schnittstelle sollte sämtliche relevanten Daten und Beziehungen innerhalb einer realistischen Zeit liefern. Zudem muss der Export ohne zusätzliche Einschränkungen weiterverwendet werden dürfen.
Cloud ist nicht automatisch gleich Abhängigkeit
Die Diskussion über Datenhoheit wird manchmal auf die Gegenüberstellung Cloud oder eigener Server reduziert. Das greift zu kurz. Eine sauber betriebene Cloud-Lösung kann bessere Exportmöglichkeiten, Dokumentation und Ausfallsicherheit bieten als eine veraltete lokale Anwendung. Umgekehrt kann eine Software auf dem eigenen Server stark an einen einzelnen Dienstleister gebunden sein.
Wir sehen On-Premises-Systeme, bei denen nur der ursprüngliche Entwickler das Datenmodell versteht. Updates sind kaum möglich, Quellcode und Zugangsdaten fehlen und Backups wurden nie testweise wiederhergestellt. Der Server steht zwar im Unternehmen, echte Kontrolle besteht trotzdem nicht.
Bei Cloud-Diensten verschiebt sich die Verantwortung. Der Anbieter betreibt Infrastruktur und Anwendung, während der Kunde Verträge, Zugänge, Exporte und Integrationen im Blick behalten muss. Diese Arbeit entfällt nicht. Sie sieht nur anders aus.
Eine gute Entscheidung orientiert sich deshalb nicht am Standort des Servers, sondern an überprüfbaren Eigenschaften: offene Formate, dokumentierte Schnittstellen, nachvollziehbare Verträge, getestete Backups, klare Zuständigkeiten und ein realistischer Wechselpfad.
Der Data Act verbessert die Ausgangslage, löst aber keine Migration
Seit September 2025 gilt der europäische Data Act weitgehend unmittelbar. Für Datenverarbeitungsdienste enthält er Vorgaben, die Wechsel zwischen Anbietern erleichtern sollen. Anbieter müssen technische, vertragliche und organisatorische Hindernisse abbauen. Verträge sollen unter anderem beschreiben, welche exportierbaren Daten und digitalen Vermögenswerte übertragen werden können.
Für Cloud- und vergleichbare Dienste ist das ein wichtiger Schritt. Der Data Act sieht offene Schnittstellen und maschinenlesbare Formate vor und regelt Fristen im Wechselprozess. Ab dem 12. Januar 2027 dürfen Anbieter für den eigentlichen Wechsel grundsätzlich keine Wechselentgelte mehr verlangen. Bis dahin können reduzierte, unmittelbar mit dem Wechsel verbundene Kosten anfallen.
Unternehmen sollten daraus jedoch keine technische Vollkaskoversicherung ableiten. Ein maschinenlesbarer Export bedeutet nicht, dass ein anderes Produkt dieselben Funktionen oder Datenstrukturen besitzt. Auch eine erfolgreiche Übertragung ersetzt keine fachliche Zuordnung. Das neue System muss wissen, wie ein alter Status, eine Berechtigung oder ein automatisierter Prozess abzubilden ist.
Der rechtliche Rahmen stärkt die Position von Kunden. Die praktische Verantwortung für Auswahl, Architektur und Migrationsplanung bleibt bestehen. Wer erst bei Vertragsende untersucht, wie seine Daten aufgebaut sind, wird trotz besserer Wechselrechte unter Zeitdruck geraten.
Verträge sollten den Ausstieg konkret beschreiben
Eine Exit-Klausel ist dann hilfreich, wenn sie technische und organisatorische Fragen beantwortet. Allgemeine Zusagen wie „Daten werden auf Wunsch bereitgestellt“ lassen zu viel offen. Bei wichtigen Systemen sollte vor Vertragsschluss geklärt werden, welche Datenkategorien exportierbar sind, welche Formate genutzt werden und wie lange der Zugriff nach einer Kündigung erhalten bleibt.
Weitere Punkte sind Unterstützungsleistungen, Kosten und Reaktionszeiten. Zu klären sind die manuelle Vorbereitung durch den Anbieter, die Startfrist, mögliche Volumengrenzen sowie die Mitlieferung von Anhängen und Protokollen. Ebenso braucht es einen Nachweis über die Löschung nach einem erfolgreichen Wechsel.
Auch Unterauftragnehmer gehören in diese Betrachtung. Eine SaaS-Lösung kann Speicher, E-Mail-Versand, Signaturen oder Analysefunktionen von weiteren Diensten beziehen. Beim Wechsel muss klar sein, welche Daten an welchen Stellen liegen und wie sie zusammengeführt werden.
Für kleine Werkzeuge muss daraus kein mehrwöchiges Vertragsprojekt werden. Der Aufwand sollte zum Risiko passen. Bei einem Newsletter-Tool, das zehntausende Kontakte und Einwilligungsnachweise verwaltet, ist eine genaue Prüfung sinnvoller als bei einer austauschbaren Anwendung für interne Notizen.
Backups beim Anbieter sind keine unabhängige Sicherung
Viele Cloud-Anbieter werben mit automatischen Backups. Diese schützen in erster Linie den Betrieb des Dienstes. Ob ein einzelner Kunde damit versehentlich gelöschte Daten in der benötigten Form zurückbekommt, hängt vom Vertrag und von den technischen Möglichkeiten ab.
Ein Backup im selben System und unter Kontrolle desselben Anbieters schützt außerdem nicht vor jedem Szenario. Wird das Konto gesperrt, endet der Vertrag unerwartet oder stellt der Anbieter seinen Dienst ein, kann auch der Zugriff auf Sicherungen betroffen sein. Für geschäftskritische Daten ist deshalb eine unabhängige, regelmäßig aktualisierte Kopie sinnvoll.
Eine solche Kopie muss nicht immer die komplette Anwendung nachbilden. Häufig reichen strukturierte Exporte und separat gesicherte Dateien. Wichtig ist, dass Wiederherstellung und Lesbarkeit getestet werden. Ein automatischer nächtlicher Export, den nie jemand geöffnet hat, ist lediglich eine Hoffnung mit Zeitstempel.
In vielen Projekten finden wir Sicherungsjobs, die seit Monaten Fehler melden, ohne dass die Meldungen bei einer verantwortlichen Person ankommen. Datenhoheit benötigt deshalb Monitoring: Das Monitoring kontrolliert den erfolgreichen Lauf, die Dateigröße, die Lesbarkeit des Archivs und die erwartete Zahl an Datensätzen.
Dokumentation gehört zum Datenbestand
Eine Datenbank ohne Beschreibung ist für das ursprüngliche Entwicklerteam oft noch verständlich. Nach einem Personalwechsel oder bei einem neuen Dienstleister wird sie schnell zum Rätsel. Tabellen- und Feldnamen erklären selten sämtliche fachlichen Regeln, die über Jahre in einer Anwendung entstanden sind.
Dokumentiert werden sollten Datenmodell, zentrale Begriffe, Schnittstellen, Exportwege und Besonderheiten. Die Dokumentation hält fest, welche ID Kunden und Verträge verbindet, welche Statuswechsel zulässig sind, wo Dokumente liegen und welche Felder personenbezogene Informationen enthalten. Solche Angaben sparen bei einer Migration erheblich mehr Zeit, als ihre Pflege im Alltag kostet.
Auch Entscheidungen sind relevant. Wenn ein Export bewusst keine internen Protokolle enthält, sollte der Grund festgehalten werden. Wenn historische Datensätze nur im Archiv bleiben, muss klar sein, wie Mitarbeitende darauf zugreifen. Ohne diese Informationen beginnt jede spätere Prüfung wieder bei null.
Wir bevorzugen schlanke Dokumentation, die regelmäßig genutzt wird. Ein hundertseitiges Konzept aus der Einführungsphase veraltet schnell. Eine kompakte Beschreibung im Repository, ergänzte Diagramme und getestete Anweisungen für Export und Wiederherstellung sind im Ernstfall wertvoller.
Abhängigkeiten entstehen auch durch Prozesse und Wissen
Technischer Vendor-Lock-in ist nur eine Seite. Ein Unternehmen kann seine Daten in einem offenen Format besitzen und trotzdem kaum wechseln können, weil sämtliche Abläufe auf die Eigenheiten eines Produkts zugeschnitten wurden. Automatisierungen, Freigaben und Berichte verwenden Funktionen, die das neue System nicht kennt.
Hinzu kommt Wissen. Wenn nur ein Mitarbeiter die Konfiguration versteht, entsteht eine interne Abhängigkeit. Verlässt diese Person das Unternehmen, wird bereits ein kleiner Umbau riskant. Dasselbe gilt, wenn ein externer Dienstleister alleinigen Zugriff auf Administrationskonten, Domains oder API-Schlüssel hat.
Datenhoheit bedeutet deshalb auch organisatorische Handlungsfähigkeit. Zugänge gehören in eine geregelte Verwaltung. Konfigurationen und Integrationen müssen nachvollziehbar sein. Mindestens zwei Personen sollten wissen, wie Exporte erstellt und geprüft werden.
Bei individuellen Erweiterungen ist außerdem zu klären, wem der Quellcode gehört und ob eine andere Agentur ihn übernehmen könnte. Exklusives Spezialwissen lässt sich nicht vollständig vermeiden. Es sollte aber nicht versehentlich an grundlegenden Betriebsaufgaben hängen.
Ein Anbieterwechsel beginnt lange vor der Kündigung
Unter Zeitdruck werden Migrationen teuer. Der alte Vertrag läuft aus, das neue System ist bereits bestellt und plötzlich fehlen Informationen über Datenmengen, Sonderfelder und Schnittstellen. Dann müssen Entscheidungen getroffen werden, bevor die fachlichen Folgen bekannt sind.
Ein vorbereitetes Unternehmen kennt seinen Bestand. Es weiß, welche Daten aktiv genutzt werden, was archiviert werden muss und welche Informationen gelöscht werden können. Es besitzt aktuelle Exporte und hat Ansprechpartner für fachliche Fragen benannt. Dadurch wird ein Wechsel planbar, selbst wenn er nie durchgeführt wird.
Für größere Systeme lohnt sich ein Exit-Plan mit drei Ebenen. Die technische Ebene beschreibt Daten, Formate, Schnittstellen und Zielinfrastruktur. Die fachliche Ebene ordnet Prozesse und Verantwortlichkeiten zu. Die vertragliche Ebene enthält Fristen, Kosten und Unterstützungsleistungen.
Dieser Plan sollte nicht ausschließlich für einen Konfliktfall gedacht sein. Anbieterwechsel entstehen auch durch Wachstum, neue Anforderungen oder strategische Entscheidungen. Wer vorbereitet ist, kann Angebote sachlich vergleichen, statt aus Angst vor einer Migration beim bisherigen Produkt zu bleiben.
So prüfen Sie Ihre aktuelle Abhängigkeit
Eine erste Prüfung lässt sich ohne umfangreiches Beratungsprojekt durchführen. Wählen Sie die fünf Systeme aus, deren Ausfall oder Verlust den Betrieb am stärksten beeinträchtigen würde. Für jedes System beantworten Sie einige praktische Fragen.
Erfasst werden Vollständigkeit und letzter Test des Exports, die Dokumentation von Format und Struktur sowie Anhänge, Beziehungen, individuelle Felder und Metadaten. Hinzu kommen administrative Zugänge im Besitz des Unternehmens und die verbleibende Abruffrist nach einer Kündigung.
Danach folgt die schwierigere Frage: Ein fachkundiger Dritter sollte mit den exportierten Informationen arbeiten können, ohne den bisherigen Anbieter um Hilfe zu bitten. Wenn die Antwort unklar ist, liegt dort ein konkretes Risiko. Es muss nicht sofort beseitigt werden, sollte aber bekannt und bewertet sein.
Bewährt hat sich eine einfache Einteilung. Grün bedeutet: Export und Wiederverwendung wurden getestet. Gelb steht für vorhandene Exportmöglichkeiten mit offenen Fragen. Rot kennzeichnet Systeme ohne unabhängige Sicherung, verständliche Dokumentation oder realistischen Wechselweg. Diese Übersicht hilft, Maßnahmen nach Geschäftswert zu priorisieren.
Offene Standards helfen, sind aber kein Selbstzweck
Offene Formate und Standards erleichtern den Wechsel, weil mehrere Werkzeuge sie verstehen. CSV, JSON, XML oder standardisierte Dokumentformate sind grundsätzlich besser übertragbar als unbekannte Binärdateien. Trotzdem sagt die Dateiendung allein wenig über Qualität aus.
Eine JSON-Datei kann technisch korrekt und dennoch kaum verständlich sein. Verschachtelte Strukturen, interne Codes und fehlende Beschreibungen erschweren die Verarbeitung. Ein CSV-Export verliert möglicherweise Beziehungen zwischen Datensätzen. Offenheit braucht deshalb Schema, Dokumentation und Beispieldaten.
Wir würden auch nicht jede spezialisierte Funktion ablehnen, nur weil sie nicht standardisiert ist. Software darf einen Wettbewerbsvorteil bieten und komplexe Probleme auf eigene Weise lösen. Wichtig ist eine bewusste Abwägung: Nutzen und Wechselkosten der speziellen Funktion sollten deshalb gemeinsam bewertet werden.
Ein Unternehmen ohne besondere Anforderungen muss nicht für maximale Portabilität zusätzliche Komplexität aufbauen. Bei Kernprozessen, die über viele Jahre laufen und zahlreiche Daten erzeugen, ist eine offene Architektur dagegen eine wirtschaftliche Absicherung.
Multi-Cloud löst nicht automatisch das Lock-in-Problem
Mehrere Anbieter parallel einzusetzen klingt nach Unabhängigkeit. In der Praxis erhöht eine Multi-Cloud-Strategie zunächst die Komplexität. Identitäten, Netzwerke, Sicherheitsregeln, Monitoring und Kosten müssen über mehrere Plattformen hinweg beherrscht werden.
Für große oder besonders kritische Systeme kann diese Verteilung sinnvoll sein. Ein zweiter Speicherort, austauschbare Infrastrukturkomponenten oder klar getrennte Dienste erhöhen die Widerstandsfähigkeit. Bei kleineren Unternehmen führt eine pauschale Multi-Cloud-Vorgabe jedoch oft zu mehr Betriebsrisiko statt zu weniger.
Der bessere Ausgangspunkt ist Portabilität. Anwendungen sollten Konfigurationen, Daten und Infrastruktur so beschreiben, dass ein Wiederaufbau möglich ist. Container, Infrastructure as Code und automatisierte Deployments können dabei helfen. Sie ersetzen aber weder Tests noch die Prüfung proprietärer Plattformdienste.
Wer eine Anwendung tief an einen spezifischen Datenbank-, Analyse- oder KI-Dienst bindet, sollte den Nutzen kennen und einen Ersatzweg bewerten. Bewusste Abhängigkeit kann wirtschaftlich vernünftig sein. Unbekannte Abhängigkeit ist es selten.
Datenhoheit ist eine wirtschaftliche Entscheidung
Vollständige Unabhängigkeit wäre teuer und in vielen Fällen unrealistisch. Jedes Unternehmen nutzt Betriebssysteme, Bibliotheken, Cloud-Dienste und Fachsoftware. Das Ziel kann daher nicht lauten, sämtliche Abhängigkeiten zu vermeiden.
Aus unserer Sicht sollten Unternehmen Abhängigkeiten dort reduzieren, wo ihr Geschäft ernsthaft betroffen wäre. Ein austauschbares Designwerkzeug braucht weniger Vorsorge als das zentrale ERP-System. Kundendaten, Vertragsunterlagen, Produktionsinformationen und individuell entwickelte Anwendungen verdienen besondere Aufmerksamkeit.
Die Kosten eines Exit-Plans lassen sich mit dem möglichen Schaden vergleichen. In die Bewertung gehören die mögliche Betriebsdauer ohne das System, die Kosten einer ungeplanten Migration, gesetzliche Aufbewahrungs- und Auskunftspflichten sowie die Folgen einer deutlichen Preiserhöhung.
Diese Bewertung führt meist zu pragmatischen Maßnahmen: bessere Exporte, unabhängige Backups, dokumentierte Schnittstellen und klarere Verträge. Nicht jedes Risiko verlangt sofort einen Plattformwechsel.
Fazit
Datenhoheit zeigt sich nicht daran, dass ein Vertrag dem Kunden das Eigentum an seinen Daten zusichert. Sie zeigt sich in der Fähigkeit, diese Daten vollständig zu erhalten, zu verstehen und ohne den bisherigen Anbieter weiterzuverwenden.
Ein Download-Button ist dafür ein Anfang, aber noch kein Exit-Plan. Beziehungen, Metadaten, Anhänge, Berechtigungen und fachliche Regeln müssen ebenso berücksichtigt werden wie Dateiformate und Schnittstellen. Unabhängige Sicherungen und verständliche Dokumentation machen den Unterschied zwischen einem vorhandenen Export und einer tatsächlich nutzbaren Datenbasis.
Der EU Data Act verbessert die Rahmenbedingungen für Wechsel zwischen Datenverarbeitungsdiensten. Technische Migrationsarbeit nimmt er Unternehmen nicht ab. Wer erst bei einer Kündigung mit der Bestandsaufnahme beginnt, bleibt von Zeit, Wissen und Unterstützung des bisherigen Anbieters abhängig.
Wir empfehlen deshalb einen einfachen Realitätscheck: Exportieren Sie die Daten eines geschäftskritischen Systems und prüfen Sie, ob ein unabhängiger Fachmann damit arbeiten könnte. Das Ergebnis liefert eine ehrlichere Einschätzung Ihrer Datenhoheit als jede Produktbroschüre.