This is the second blog on Agile PLM data migrations. My prior post "Agile PLM Data Migration – Part 1: Anatomy of an Agile PLM Data Migration" covered the typical process I use while performing a migration and this post will aim to set the stage for a sample migration of a document object with the assignment of a revision, requiring a change order. As mentioned in the first blog, there are a lot of other posts and books on migrations but seeing it is a lot different than reading about it from a theoretical point of view (or from someone who hasn't actually done one).
Imagine, if you will, that you have 10,000 documents to migrate. All of which were released in the legacy document management system on different dates. This would be a great job for the DataLoad tool because we can easily create all change orders in a released status and assign the desired revision to the imported documents. This is a Oracle Consulting Services and Partner only tool designed specifically for data migrations. It has the ability to reproduce revision history and load most object types, not just Items. The purpose of this blog is not to provide a tutorial on the DataLoad tool, but rather to give a high level overview of how an Agile PLM migration can be accomplished with a real example.
There are many books and blogs on data migration, several of which even pertain to Agile PLM, but most of what I have seen reads more like a sales presentation or material put together by someone who hasn’t personally dug in to understand how to get the migration done. This blog is the first in a series to address HOW an Agile PLM migration is done from a technical perspective.
- Agile PLM Data Migration – Part 1 (this blog): Anatomy of an Agile PLM Data Migration
- Agile PLM Data Migration – Part 2: Data migration execution - setting the stage
Validation requirements, data sampling sizes, etc. are all important topics for data migration but I consider them more of the business unit’s responsibility as I have never been a fan of having developers performing quality control against the product of their own deliverable. Naturally unit testing should be performed by the migration expert along the way. So what does a real world data migration look like?