Not Another Pro/CONVERT

I have heard the stories of customers migrating hundreds of Pro/PDM databases to Pro/INTRALINK; dealing with a rat's nest of duplicate objects; overcoming corrupted databases; managing files on local disk while the migration process continues. For some it was definitely a struggle. Pro/CONVERT did its job, but we wanted to do better.

When we started this project nearly 2 years ago we spent time looking back at the Pro/CONVERT experience. This includes interviewing people internally as well as discussing migration experiences with some of our customers. Some of the things we learned included:

• Minimize downtime impact
• Consolidation of Pro/INTRALINK Commonspaces
• Documentation has to be more robust

Migration Downtime Impact
Unfortunately, migration does require a period of downtime. It is critical that the source system be static at the time of migration to eliminate the introduction of unknown conflicts. This is something that we have to live with. The challenge has been to shrink this period to a reasonable level. Let's say a 3-day weekend. For a typical customers database (say 500,000 PIVs, 20 attributes) we believe that this has been accomplished. One aspect to this migration that is a definite benefit is that we are moving from one Oracle database to another Oracle database (unlike Convert which had to deal with a homegrown database solution). The direct database-to-database aspects of this migration provide the performance results we were looking to achieve. Moreover, the fact that it is Oracle-to-Oracle virtually eliminates the corruption concerns that existed with Pro/CONVERT.

Commonspaces
Many customers, due to WAN performance issues or through acquisitions, have deployed multiple Pro/INTRALINK Commonspaces throughout their company, or division. They would prefer to manage all of this data in a single database environment. You can imagine that this could be quite an undertaking. The good news is that, unlike Pro/CONVERT, the Pro/INTRALINK Data Migrator lets you migrate each of these commonspaces independent of one another, allowing you to stagger your migration effort on a database, by database basis.

Documentation
Since every customer situation and migration is unique it is important that the documentation be comprehensive so that users have the knowledge in hand to tailor their migration to meet their needs. In my opinion, the Pro/INTRALINK Data Migrator Administration Guide addresses this concern. The documentation in conjunction with the best practices learned from the Migration training course should go along way in helping you plan and execute and effective migration to Pro/INTRALINK 8.0. Although under the revised Pro/INTRALINK Data Migrator (see Jim's blog) delivery plan the tool won't be posted for general availability until mid-October, the documentation is. I might suggest that you take a look. Is there something you don't understand or needs clarification? Let us know what you think in our forums. We want your feedback. There is always room for improvement!