Planning And Implementing Digital Asset Migration
A couple of weeks ago, CMSWire ran an article by Jeff Lawrence of Celerity with the title: Using DAM Content Migration to Maximize Asset Value. It has taken me a while to find the time to catch up and read this item but DAM migration is a subject I have some prior experience of, so I was interested to see what Jeff had written. I am glad I did as it does contain some useful points, such as this one:
“Don’t underestimate how long a content migration phase will take! Take the time needed to create a migration plan. The best approach is to use an agile methodology to incrementally extract, transform and load assets into the new DAM. Before creating a content migration plan, there needs to be a deep understanding of all assets to be migrated. The best place to start is by conducting a comprehensive content inventory. This inventory must include all assets that will be migrated into the new DAM or might be considered for migration at some point in the future.” [Read More]
A lot of organisations are now on at least their second iteration of Digital Asset Management and many may also be discovering they hold a multitude of hitherto little-known asset repositories (or ‘silos’ to use the currently fashionable pejorative expression). As I discussed on DAM News recently, legacy metadata is likely to be an increasingly significant issue in DAM as users have to take difficult decisions about what is likely to be worthwhile retaining. A key part of that is understanding what will be involved in migrating the data contained.
Based on migration exercises I have been involved in, the level of effort required is typically greater than was originally anticipated, with the complexity of the task being roughly proportional to the age of the system. Legacy migration is a bit like holding on to the proverbial balloon, the longer it gets left undone, the harder it becomes and the more knowledge and expertise is at risk of ebbing away due to key staff leaving, lost documentation or people just simply forgetting the salient details of how something was set up (and why, more importantly).
The major theme of Jeff’s article is migration as an opportunity to enhance the value of assets, for example conversion of asset types away from old and unused formats. A lot of the focus on migration activity is centred on not losing anything and preserving the original state as far as possible. To handle the process comprehensively, the original should be kept as well (in case some issue is found with the conversion) but I understand what he means and he makes a good point, one of many, in fact.
The article includes a checklist of items to be considered for inclusion in a content inventory:
- Asset types
- Metadata schemas (fields)
- Asset usage records
- Total size and number of assets
- Access Control Lists (ACL) / Security / Risks
- Digital Rights Management (DRM)
This should indicate that the migration is more involved than just mapping the asset metadata records into the new edition, which is often the misunderstanding that implementation teams make (and the source of numerous underestimations of the effort likely to be required).
I am not entirely sold on using the agile methodology exclusively for all software implementation activities, since I have seen it abused by some as a means to get out of committing to deadlines and deliverables, however, in the case of migration, I would have to agree that it is the only practical way to do it because there are so many unknown factors. You need to get a good idea of the full scope before proceeding and deciding whether or not to scale back any migration ambitions (as well as how to safely phase them in a manner that will not impact ROI or generate unnecessary disruption).
As well as this piece, I have found David Hobb’s articles to be useful on the migration subject. Although they are not about DAM specifically, there is sufficient read-across to make them well worth checking out also if you have a complex migration job heading your way and want to get clued up on best practices.Share this Article: