Most DAM projects require some kind of migration these days as it is becoming rarer to find implementations where at least some kind of rudimentary facility was not in place initially. In many cases, it’s worse for earlier adopters of Digital Asset Management where the potential for some obscure, unsupported or unconventional technologies and/or data sources to be encountered is far greater.
In this CMSWatch.com article, Apoorv Durga asserts that Content Migration should follow a similar process to a conventional software project with defined stages for analysis, design, implementation, testing and deployment:
“Most organizations do not undertake a migration effort with the rigor and discipline that they normally would for a software project. The result is often a failed migration. You should treat a content migration project like any other major software project in terms of execution. What this means is that you should deploy a proper methodology for implementing migrations.” [Read More]
Those with a formal CS (Computer Science) background may have noticed that this model appears to recommend a return to the classic ‘waterfall’ model of software development, however, Durga does point out that that the principles of should be applied depending on the project delivery methodology:
“Depending on whether you use Waterfall, Iterative, RUP, Agile or some other methodology, there will be variations in the way you carry out some of the migration activities. However, the point is that you should treat content migration just like you would treat any other project and give it the respect it deserves.” [Read More]
- Metadata Automation Webinar Recording From New Jersey DAM Meetup Group
- Can Enterprise Taxonomy Management Survive Analyst Reticence - And Does Anyone Else Care Anyway?
- The Role Of Taxonomy Governance In DAM Interoperability Initiatives
- Google's Visual Case Study Of The Perils And Politics Of Automated Metadata
- The Perils And Politics Of Automated Metadata Generation