Bookmark
- Alfresco Developer Guide released
- Drupal, Acquia, and 2009
- Open Source Year 2008 in Review: More Adoption, Success, Innovation, and Alternatives
- Open Source Catalogue 2009 generates high interest and confirms the relevance of Open Source for Enterprises
- Open Source Content Management Panel at Gilbane Boston
- Designing for the Social Web
After the first and successful implementation of Alfresco at the State of Vaud (Switzerland), the IT department sees more and more requests of State departments requesting for integrating the Alfresco ECM platform. One usual need is the data migration from an existing application to the Alfresco ECM repository. The easiest case is - of course - when Business does not require any migration as the new the application will manage new content only.
The intermediate case is when a single shot migration is required in order to feed the repository with the initial content. The complex case arise when: i/ a migration of initial content is needed and ii/ a synchronization mechanism is needed in order to keep data updated between applications. One concrete example is when users do have a legacy front-end application that stores data into a file system and the decision is made to move the data into the Alfresco ECM repository for new features like extended search, versioning, etc. Both intermediate and complex cases can lead to very complex mechanisms of migration and synchronization of data. It is crutial to plan enough time for migration of data as communication issues will always arise: the migration into Alfresco will depend of 1/ the quality of the communication channels (ftp or other), 2/ the performance and availability of the third applications/stores from where to retrieve data and 3/ the quality of data from the external systems/stores. One technique that can enhance the migration procedure is the ability to categorize content and data: sometimes in a huge set of content, one can categorize content and data and the migration/synchronization mechanism can be validated through the use of subset representative of each category of content. This is usually feasible/reachable when the quality of data is enough homogeneous. As a standard practice, we will exclude data migration from our fix time / fix cost offering, since the risk is simply too high as we are not owner of the external systems from where we will need to migrate the data from. However, we see more and more data migration projects and the challenge is to find a creative way to minimize the risk in order to provide a fix time / fix cost offering.

