DAM-Migrationen scheitern selten am Migrationstool, sondern meist an den Daten selbst und an fehlender Mapping-Logik. Typisch sind Bemerkungsfelder, in denen Copyright, Angaben zum Fotografen und Bildinhalte gemeinsam stehen, obwohl es dafür eigene Felder gäbe. Hinzu kommen leere Pflichtfelder, inkonsistente Werte wie «de» und «Deutsch» oder Freitext-Tags, in denen Zürich in mehreren Schreibweisen vorkommt. Oft trägt zudem die Ordnerstruktur Informationen wie Region, Produkt oder Jahr – und nicht das Asset selbst.

Eine DAM-Migration läuft in sechs Schritten ab: Analyse, Export, Mapping, Transformation, Import und Validierung. Der Export, der auch live über eine API erfolgen kann, und der Import lassen sich automatisieren, ebenso die Transformation der Metadaten, etwa mit einem Service wie dem General DAM Migrator. Am meisten Zeit kostet das Mapping, also die Frage, welche Information aus dem alten System in welchem Feld des neuen landen soll. Eine Vollautomatisierung per Knopfdruck gibt es nicht: Die Mapping-Entscheidungen müssen vor der Migration definiert sein. Nach dem Import werden die Daten validiert und bei Bedarf in weiteren Durchläufen korrigiert.

Was bedeutet Transformation bei einer DAM-Migration?

Bei der Transformation werden Daten nicht kopiert, sondern so aufbereitet, dass sie ins neue Datenmodell passen. Dazu gehört, Werte zu vereinheitlichen – etwa wenn ein Namensfeld bis zu 30 Ausprägungen hat oder aus «MKT» einheitlich «Marketing» werden soll. Felder werden aufgeteilt, z. B. ein Textfeld mit Copyright- und Nutzungsangaben in mehrere Felder wie Nutzungsbedingung und Lizenz, oder umgekehrt aus mehreren Feldern zusammengeführt. Informationen aus Ordnerpfaden, etwa Jahr und Kampagne, werden als Metadaten aufs Asset geschrieben, damit sich danach filtern lässt. Hilfsmittel sind Mapping-Tabellen; wo Daten ungeordnet in Feldern stehen, ist eine Korrektur im alten DAM nötig. Die Kundinnen und Kunden sind in diesen Schritt stark eingebunden.

Der Aufwand einer DAM-Migration sollte nicht unterschätzt werden. Die meiste Zeit fliesst in die Analyse sowie in die Definition der Mapping- und Transformationsregeln. Ist festgelegt, was von A nach B kommt, ist die eigentliche Migration per Knopfdruck nicht mehr aufwendig. Wichtig ist, Testmigrationen früh und mehrfach durchzuführen; je nach Tool lassen sich dabei nur die Metadaten aktualisieren, ohne die Dateien erneut zu übertragen. Auch Fehler sollten Sie einplanen: Eine Migration gelingt selten im ersten Durchlauf, und Assets mit nicht korrigierbaren Informationen können Sie bewusst ausschliessen.

Ja, mit einer Delta-Migration. Weil eine Migration Tage, Wochen oder sogar Monate dauert und Umsysteme auf aktuelle Daten angewiesen sind, ist ein kompletter Freeze oft keine Option. Bei der Delta-Migration hält man fest, wann welche Daten exportiert wurden, und zieht neue Dateien und geänderte Daten nach. Am elegantesten ist es, nur neue Dateien nachzuliefern und Änderungen auf ein Minimum zu beschränken, denn Änderungen durchlaufen wieder Mapping und Transformation – mit dem Risiko neuer Fehler.