Reviewing Existing DAM Solutions: Part 3

In the previous two parts to this article, I examined these topics:

• Identifying sources of existing assets
• Lessons that could be learned from how things were done before (and why)
• Legacy systems
• User feedback and behavioural data

In this final item, I will discuss the issues you need to think about to migrate to your new DAM system and items to consider when reviewing your current one.

Migrating From A Legacy DAM System

If you have existing applications that are either DAM systems or have similar functional characteristics, legacy data migration will be a task that you must engage with if you intend to retain any of the asset files and/or metadata they contain.

DAM system migration used to be a fairly arduous and complex undertaking because many older applications were developed using proprietary databases and lacked reliable data export capabilities. Due to the widespread use of relational databases and proliferation of technical standards in the wider software market, that is less likely to be the case these days, but if you have to move away from a system that dates from the 20th century (and still one or two from more recent times) then you might still encounter some problems with legacy data.

Even though the engineering complexity has reduced, the project management of migration work packages has not got any easier. In some ways, because there is an expectation that all legacy data can be retrieved the technical challenges have transferred upwards instead as managers may have to make potentially controversial decisions about ROI whether a specific migration requirement is justified from a business perspective.

There are several types of data elements to consider in DAM migration:

• Asset Files
• Asset Metadata
• User Data
• Business Rules
• Transactional And Auditing Data

You might encounter further sub-types and other task-specific issues, but the above should cover most of what you will have to think about.

Asset Files
If the legacy system held digital assets (rather than just pointers to analogue or external data), these are obviously an essential item to migrate. With that being said, they are usually easier than the other aspects described above because they are typically complete and self-contained files. The key issue with asset files is compatibility and traceability of the referencing system used in the old with the new. As part of your review, you need to work out a method for how you will find assets in the new system with reference to the indexing approach of the old.

Asset Metadata
This is quite rightly the major focus of any DAM migration task. All that metadata held about assets represents stored knowledge which your firm had to pay its employees and suppliers to generate across the entire lifetime of the system. For that reason, if you want to ditch some metadata, you need a good reason why it is no longer useful as you are effectively writing off the value of it as now being totally worthless. That is sometimes a hard decision to make before the new DAM system is put into service, so if you do decide not to migrate some data, it is worth retaining it in a neutral format (e.g. a spreadsheet or data files) so it can be reviewed later and potentially re-imported.

User Data
With DAM systems, there is often a multi-faceted relationship between users and assets since they are the two key entities. A lot of the core data will probably still be needed, such as name, email address, telephone etc. If your new DAM solution is integrating with some corporate authentication system like Active Directory, not all of that may be required nor even desirable (especially old passwords). Even if you ignore a lot of the legacy user data, you will still need the index or reference number so any transactional data (like who downloaded what and when) is not orphaned.

Business Rules
This includes data like order processing workflow. It will usually be fairly messy to migrate because the new system is likely to handle everything completely differently to the old one (and was probably a key reason why it was commissioned to begin with). In my experience, unless there are thousands of complex or intricate business rules, this is one migration element that is easier to manually re-apply, where relevant. With that said, there are no hard and fast rules and you need to examine the pros and cons of an automated migration.

Transactional and Auditing Data
The extent to which this is worth migrating needs to be carefully assessed. There might be a legal obligation to retain some transactional data (e.g. if used for accounting purposes or some legal compliance reason). A lot of time can be saved by not bothering to migrate user auditing data as there is usually a lot of it and it needs to cross-refer to both uses and assets, however, it is also a potentially valuable business intelligence resource that becomes lost if not transferred into a new DAM solution. If you have the budget then I would advise migrating this or at least developing some methods to allow the data to still be queried so there is a route back to accessing this later.

Conclusion & Advice For Managers
Many managers who have executive responsibility for a DAM implementation may take the view that migration choices are too low level for them and decisions should be left with database and software people. In the main, that would be correct, however, migrations can be a more risky undertaking than other types of DAM implementation work and for that reason, you need to have a full grasp of what the risk factors are and how the delivery team are going to ensure they are managed and mitigated.

One of the big dangers with migration exercises is that you do not find out that some fatal error was made until a reasonable amount of time has passed – when it is far harder to address because the replacement DAM is now in full swing and being widely used across the business. To avoid this, a careful balance is required between not micro-managing the technical team and ignoring the issues because they are dry or difficult to understand. The best technique I have encountered seems to be to ask many questions about how the migration will be achieved – it doesn’t matter whether these are technical or not, just how the plan will work. If the people involved in the migration implementation are skilled and experienced, they will have answers at their fingertips, or be able to get them quickly.

I have found non-technical people to be better at this kind of deductive analysis because they do not feel so encumbered by the need to demonstrate they understand the subject and can ask what appear to be questions with obvious answers but frequently may not have been properly assessed. If you do not consider yourself to fulfil an engineering related role on the delivery team, the points to watch out for are embedded assumptions in the reasoning of a developer or database administrator. For example, they might say something like: “this will be an easy task, we only have 10 tables that we need to migrate”. A response might be to enquire what that encompasses in terms of operational data. The engineer might then reveal that they were not going to migrate user auditing details because they did not believe it to be of value (or required). The implication of that assumption is that you will lose auditing data from the legacy application. That may or may not be important (or feasible to deliver), but straight away it reduces your ability to compare the old and new systems unless the old system is maintained. How important that will be depends on your circumstances. If the old DAM was heavily used, it is more important, whereas if it has been essentially abandoned, perhaps less so.

The other extreme I have seen on some occasions is managers requiring developers to migrate everything to avoid making the wrong decisions about what to keep or drop. This is not usually a practical option, because the other big factor is cost (which nearly always means the time billing expense of the vendor’s professional services team and/or other in-house implementation personnel). Your ROI case needs to carefully weigh up the benefits of keeping legacy data as compared with the cost of not migrating it. In some cases, there are hybrid options which are just as good, for example transferring it to a spreadsheet where it can still be analysed, just not through the system. The objectives of the manager and the implementation staff need to be aligned, that does not mean they ignore anything complicated you ask of them but neither does it imply you require every last detail to be migrated just because it might potentially be needed at some non-specific point in the future. DAM migration isn’t an all or nothing proposition, it’s a case of assessing the costs and benefits and keeping the business case at the forefront of all decisions.

As you can see across these three articles, reviewing existing DAM systems can reveal a lot of data that has useful lessons for any future implementation. In doing so, you need to draw a balance between ‘analysis paralysis’ where you are stymied by too much data and indecision about how to proceed lest you get it wrong and the other polar opposite where there is no consideration of existing digital asset provisions with the consequence that the same mistakes get made again. As has been pointed out by several commentators, Digital Asset Management is not about DAM software but is more a series of techniques to ensure you get maximum value from the not inconsiderable sum your organisation has invested into digital assets already (let alone how many more you will acquire or originate in the future). A comprehensive review of what you already have is therefore an integral element of your DAM implementation project planning.

Share this Article: