Ich sitze gerade an einem Projekt, bei dem ich historische Bestelldaten mit den aktuellen Produktkatalogen abgleichen muss. Die alten Datensätze sind in einer ziemlich chaotischen CSV-Landschaft gefangen, und ich frage mich, ob es einen sinnvollen Weg gibt, diese Datenmigration zu strukturieren, ohne in monatelange manuelle Bereinigung zu versinken. Irgendwie muss ich diese veralteten Informationen in unser neues System überführen.
Eine sinnvolle Reihenfolge für die datenmigration ist zwei schritte zu definieren. Erst eine mapping spekifikation die alten felder den neuen attributen zuordnet und dann ein dry run mit einer testmenge um fehler zu finden. Danach den prozess in eine staging umgebung überführen und versionieren damit klar bleibt was sich verändert.
Ich bevorzuge einen modularen ansatz bei dem die daten in kleine module zerlegt werden. Erst mapping dann bereinigung der duplikate und danach der abgleich mit dem aktuellen produktkatalog. Zwischendrin bleiben klare logs damit auffaelligkeiten sichtbar sind.
Vielleicht ist die einfache frage nach migration falsch gestellt. Wer garantiert dass alte bestell daten sinnvoll ins neue system passen ohne kontext aus dem business zu erfassen? Vielleicht reicht es aus die alten daten als referenz zu halten und nur relevante fakten abzuleiten.
Ich verstehe das thema so dass man alle alten produktenamen eins zu eins in den neuen katalog kopiert. Das klingt logisch, aber was wenn die alten codes gar nicht mehr gelten und wir nur eine grobe mapping idee brauchen?
Man koennte den vorgang als bruecke sehen zwischen alten codes und neuen attributen und die idee des master data management mitbringen ohne zu versprechen dass alles perfekt wird.
Oh man das ist wirklich nervig ich spuere die kopfschmerzen der datenflut aber vielleicht steckt darin auch chance neue muster zu erkennen.
Dieser ansatz fuehrt das konzept context basierte mapping ein statt einer exakten kopie und fuehrt das thema data stitching ein ohne es zu erklaren
