Frank Dolibois
CEO – YourInsight | Data- and Migration-Expert | Agentic AI | Web3 Advisor | Business-Analyst | Investor
11. Mai 2026
Das ist der Satz, nach dem sich viele Projekte selbst auf die Schulter klopfen und genau das ist meistens der Moment, in dem sie anfangen, Schaden anzurichten.
Nehmen wir ein typisches Beispiel: Ein Unternehmen ersetzt ein zentrales Legacy-System. Das System ist über 20 Jahre gewachsen, hochgradig individualisiert und tief in die Geschäftsprozesse integriert. Ziel ist eine moderne Plattform mit klarer Architektur, besserer Integrationsfähigkeit und zeitgemäßen Analyseoptionen.
Die Rollen sind formal klar verteilt. Die IT verantwortet Architektur, Plattform und Migration. Die Fachbereiche liefern Anforderungen, testen Szenarien und nehmen ab. Data Owner sind benannt – zumindest auf dem Organigramm. Auf dem Papier sieht das sauber aus.
Die IT macht ihren Job. Zielmodell entworfen, Schnittstellen definiert, Mappings erstellt. Daten werden transformiert, validiert, gezählt. Der Fokus liegt auf technischer Korrektheit: Datentypen, Pflichtfelder, Referenzen. Der Cutover ist minutiös geplant, der Go-Live verläuft stabil. Projektstatus: grün.
Kurz danach beginnt die Realität. Die Fachbereiche merken schnell: Zahlen sehen anders aus. Nicht offensichtlich falsch aber nicht mehr eindeutig vertraut. Historische Reports lassen sich nicht mehr sauber vergleichen. Entscheidungen brauchen mehr Abstimmung. Aussagen werden vorsichtiger formuliert.
Die Daten sind da. Aber niemand fühlt sich mehr sicher. Jetzt beginnt das klassische Rollenspiel.
Die IT verweist auf erfolgreiche Migrationstests. Alle Daten sind übernommen. Die Logik entspricht dem Zielmodell. Abweichungen seien fachliche Fragen, keine technischen Fehler.
Der Fachbereich reagiert irritiert. „So haben wir damit aber jahrelang gearbeitet.“ Bestimmte Felder waren immer gefüllt. Bestimmte Codes hatten eine klare Bedeutung auch wenn sie nie sauber definiert war. Das System mag technisch korrekt sein, aber fachlich fühlt es sich falsch an.
Und der Data Owner? Der sitzt plötzlich zwischen den Stühlen.
Denn genau hier wird sichtbar, was in vielen Projekten verdrängt wird: Data Ownership wird gerne formal vergeben aber selten mit echter Entscheidungsmacht ausgestattet.
Im Beispiel war ein bestimmtes Feld im Legacy-System faktisch verpflichtend. Nicht, weil es technisch so definiert war, sondern weil ein etablierter Prozess es verlangte. Diese Regel stand in keiner Spezifikation. Sie lebte im Alltag.
Im Zielsystem wurde das Feld optional modelliert. Architektonisch sauber. Flexibel. Zukunftsfähig. Technisch kein Fehler. Fachlich ein Bruch.
Die IT hat korrekt umgesetzt, was spezifiziert war. Der Fachbereich erkennt die Konsequenzen erst im Betrieb.
Der Data Owner hätte entscheiden müssen: Übernehmen wir diese implizite Regel bewusst oder schaffen wir sie ab? Aber diese Entscheidung wurde nie getroffen. Nicht aus Unwillen, sondern weil niemand sie eingefordert hat.
Ein weiteres Muster zeigt sich beim Go-Live. Formal gibt es eine fachliche Abnahme. Testfälle sind durchlaufen, Stichproben geprüft. Was fehlt, ist eine andere Perspektive: Vertrauen.
Denn ab dem Go-Live treffen Menschen Entscheidungen auf Basis dieser Daten und sobald sie anfangen, parallel zu rechnen, alte Exporte zu ziehen oder Excel-Listen zu pflegen, ist die Migration faktisch gescheitert egal, wie stabil das System läuft.
In unserem Beispiel passiert genau das. Nicht, weil jemand blockiert, sondern weil niemand die Verantwortung übernimmt zu sagen: „Ja, diese Daten sind jetzt die neue Wahrheit.“
Und genau hier entscheidet sich der Unterschied zwischen Rollen auf dem Papier und Rollen in der Realität:
- IT kann Systeme bauen, aber keine fachliche Bedeutung garantieren.
- Fachbereiche kennen die Realität, aber nicht immer die Konsequenzen technischer Entscheidungen.
- Data Owner müssten vermitteln, entscheiden und priorisieren werden aber oft zu Abnehmern degradiert.
Migration scheitert in solchen Beispielen nicht an Tools oder Plattformen. Sie scheitert daran, dass niemand die fachliche Deutungshoheit über Daten aktiv übernimmt.
Eine saubere Migration braucht deshalb mehr als gute Technik: Sie braucht Data Owner, die entscheiden dürfen und müssen. Sie braucht Fachbereiche, die implizite Regeln explizit machen. Und eine IT, die nicht nur umsetzt, sondern Widersprüche sichtbar macht.
Solange Migration als IT-Projekt behandelt wird, bleiben diese Spannungen ungelöst. Und solange Data Ownership keine echte Verantwortung ist, bleibt fachliche Bedeutung Zufall. Datenmigration ist der Moment, in dem Organisationen lernen, ob ihre Rollen wirklich funktionieren oder nur gut benannt sind.
Wo scheitert Data Ownership in euren Projekten am häufigsten: an fehlender Zeit, fehlender Entscheidungsmacht oder fehlender Klarheit über die eigene Rolle?
#DataMigration #DataOwnership #LegacySystems #Projektrealität
