Antwort.

In der Geschichte der IT-Welt waren Datenmigrationsaufgaben oft Quelle unerwarteter Pannen: Verzerrung, Verlust oder Duplikation von Informationen, insbesondere in großen, vielfältigen Informationskonstrukten (z.B. bei der Umstellung von Monolithen auf Mikrodienste oder von Legacy-Plattformen auf moderne Lösungen).

Das Problem liegt im Fehlen einer einheitlichen Vorstellung von Migration: Auftraggeber oder Entwickler betrachten diese Aufgabe oft nur als technische Herausforderung, ohne die Risiken für Geschäftsprozesse zu bewerten und Grenzfallszenarien (Datenformatinkongruenzen, Strukturen, Verlust von einmaligen Geschäftsregeln in dem alten System) zu durchdenken.

Die Lösung besteht in einem systematischen Ansatz:

Vollständige Inventarisierung der Datenmodelle, einschließlich nicht offensichtlicher Verbindungen und Geschäftsregeln.
Entwicklung detaillierter Migrationsszenarien: Was passiert mit historischen, nicht aktuellen, phantomhaften und isolierten Daten?
Aufnahme der Migrationsanforderungen in die Dokumentation in klarer Form, einschließlich der Reihenfolge der Datenladung, der Rückrollmethoden sowie der Prüfungen auf Vollständigkeit und Richtigkeit der Übertragung.
Festlegung von Risikozonen: Was wird nicht übertragen, warum und wie wird dies dokumentiert.

Wesentliche Merkmale:

Enge Kommunikation zwischen Business Analyst, Architekt und DBA erforderlich.
Immer eine Validierungsstufe der Migration hinzufügen (z.B. selektive Replikation und anschließende Prüfung).
Facettierte (schrittweise) Dokumentation: Was wird vollständig, was teilweise und was erfordert manuelle Bearbeitung.

Trickfragen.

Kann die Datenmigration ohne Beteiligung der Fachabteilungen durchgeführt werden, wenn "alles in der Datenbank vorhanden ist"?

Nein, ohne die Beteiligung des Geschäfts ist es unmöglich, die Validität, Kritikalität und Aktualität der Daten zu bestimmen. Alte Geschäftsregeln, auch wenn sie nicht formal dokumentiert sind, können den Lebenszyklus von Informationen beeinflussen.

Muss man alle Felder aus dem alten Datenmodell im neuen System beibehalten?

Nicht immer: Einige Felder können rudimentär oder ohne Bedeutung sein. Diese Entscheidung muss jedoch abgestimmt und in der Dokumentation festgehalten werden, andernfalls besteht das Risiko der Inkonsistenz von Geschäftsprozessen.

Kann man sich mit einer selektiven Migration nur "frischer" Daten zufrieden geben?

Das hängt von den Geschäftsanforderungen ab. Oft werden historische Daten für Berichterstattung, Compliance oder Audits benötigt. Eine selektive Migration ohne Abstimmung birgt das Risiko des Verlusts rechtlicher oder betrieblicher Informationen.

Typische Fehler und Anti-Patterns

Fehlende Spezifikation der Datenumwandlung (welche Felder werden konvertiert und wie).
Auslassen von Attributen, die downstream-Prozesse beeinflussen.
Ignorieren des Bedarfs an Retests und Audit-Tracking von Migrationen.

Beispiel aus dem Leben

Negativer Fall: Eine Bank stellte auf ein neues CRM-System um; die Analysten hatten die Zusammenhänge zwischen dem Wohnort des Kunden und regionalen Steuervergünstigungen nicht festgehalten. Dies führte zu Fehlern bei der Bonusberechnung.

Vorteile:

Schnelle Umsetzung der Lösung.

Nachteile:

Tausende Entschädigungszahlungen an Kunden.
Juristische Risiken und Vertrauensverlust der Kunden.

Positiver Fall: Vor der Migration erstellten die Analysten eine detaillierte Attributkarte, führten eine Pilotauswahl und Datenausladung durch, testeten die Richtigkeit jeder Transaktion an zufälligen Kunden und stimmten alle Szenarien mit dem Geschäft und dem Publikum ab.