Der Anstoss für eine DAM-Migration kommt meist aus mehreren Problemen gleichzeitig, und diese liegen häufiger in Prozessen und Organisation als in der Technologie. Typisch sind Prozesse, die nicht mehr funktionieren, in die Jahre gekommen oder nie sauber durchdacht worden sind. Dazu kommen Inhalte, die an verschiedenen Orten und in verschiedenen Systemen liegen, sodass Mitarbeitende im Alltag viel Zeit verlieren, bis sie die richtigen Assets finden. Oft entsteht zudem der Eindruck, das bestehende DAM-System leiste nicht mehr, was es sollte, obwohl sich eigentlich die Art der Nutzung über die Zeit verändert hat.

Rollen und Verantwortlichkeiten sollten bei einer DAM-Migration neu definiert und nicht aus dem alten System kopiert werden. Lief im alten System etwa alles bei einer Person zusammen, von den Strukturen über Metadaten und Freigaben bis zum Support, passt das oft nicht zur Architektur des neuen Systems, und kopierte Rollen führen zu Lücken und Konflikten. Binden Sie deshalb früh die Power-User ein: Sie kennen die Schwächen des alten Systems, und ihr Wissen ist häufig nicht dokumentiert. Ohne sie werden alte Abläufe im neuen System leicht nachgebaut, statt sie zu verbessern. Mit ihnen klären Sie auch die Data Governance: wer wofür zuständig ist, wer Felder anlegen darf, wie Assets freigegeben werden und wer über die Taxonomie entscheidet.

Akzeptanz entsteht bei einer DAM-Migration, wenn Sie die Nutzerinnen und Nutzer früh einbeziehen und ehrlich kommunizieren, was sich für sie konkret ändert. Auch eine technisch einwandfreie Migration kann scheitern, wenn Menschen das neue System ablehnen: Vertraute Abläufe funktionieren nicht mehr, man ist anfangs langsamer und macht Fehler. Bewährt hat sich, Power-User früh in die Konfiguration einzubinden, rasch einen Prototyp zu erstellen, Feedback einzuholen und erst danach zu schulen. Schulungen sollten sich an den konkreten Anwendungsfällen orientieren und erklären, wie etwas im alten System lief, wie es jetzt umgesetzt ist und warum. Ein Warnsignal ist, wenn das alte System nach der Migration parallel weiterläuft; die Nutzungsdaten zeigen, ob das neue System tatsächlich verwendet wird.

Nein, eine DAM-Migration ist keine Kopie des alten Systems, sondern das Aufsetzen eines neuen, und auch Metadaten und Berechtigungen müssen neu gedacht werden. Metadaten sind über die Jahre oft gewuchert: Felder werden kaum genutzt, bleiben leer, oder dieselbe Information steht in verschiedenen Feldern. Eine Bestandsanalyse mit den heutigen Nutzerinnen und Nutzern zeigt, was es noch braucht. Daraus entsteht ein Mapping auf das neue System, das aufwendig, aber für das Gelingen der Migration entscheidend ist. Berechtigungen lassen sich technisch nicht übertragen, weil jedes DAM-System sie anders umsetzt, etwa über Ordnerstrukturen, Metadaten oder eine Kombination. Klären Sie sie früh und halten Sie sie möglichst einfach, denn kommen sie erst nach der Übernahme der Assets auf den Tisch, muss unter Umständen der gesamte Datenbestand neu organisiert werden.

Bei einer DAM-Migration sollten Sie zuerst die Prozesse klären und erst dann Schnittstellen bauen und automatisieren. Ein DAM ist selten eine Insel, sondern meist mit Systemen wie CMS, PIM oder Shop verbunden. Oft laufen dabei noch viele Schritte manuell, etwa wenn Bilder in anderen Auflösungen heruntergeladen und im CMS wieder hochgeladen werden. Die Migration ist eine gute Gelegenheit, solche Abläufe sichtbar zu machen und zu prüfen, wie sich Importe und die Verteilung in andere Systeme automatisieren lassen. Wer umgekehrt vorgeht und etwa ohne geklärte Freigabeprozesse eine Integration baut, beschleunigt das Problem, statt es zu lösen: Formate passen nicht, und Daten stimmen nicht. Planen Sie Integrationen deshalb früh in Zeitplan und Budget ein und testen Sie so früh wie möglich.