When you import NX parts and drawings into Teamcenter there are two main challenges. The first is selecting the right item ID. I previously covered how to automate that by implementing a custom clone-autotranslate function. The second is selecting the right item type. Today I’ll show how to automate that by writing a custom Convert callback.

I started this series on what I’ve learned about migrating CAD data into Teamcenter a couple of weeks ago. The more I write, the more I find there is to write; as I pull on the thread of memory more and more details are pulled to the surface.

I was working on a different post in this series when I realized that what I had missed was a look at the big picture: what does you native data look like? What does your Teamcenter look like? What must you maintain when you migrate? These are the sorts of questions that will help you understand the complexity and level of effort you can expect from your CAD migration project.

I believe that working through the following questions will help you to shape an effective migration plan. If you can think of any others please share them in the comments below.

Last time I discussed the problems with native NX CAD files while data migrations into Teamcenter that I’ve seen. This week we’ll begin looking at how to proceed with the migration — or at least what I’ve done. What I did may not work for your situation, but at least it should give you something to think about.

The subject of migrating NX CAD data into Teamcenter has come up recently in discussions I’ve been involved with. Data migrations have also been one of the more interesting projects I’ve personally worked on, so I thought it might warrant a post or two.

I’m going to start off buy discussing some of the problems I’ve seen with the raw data, the part files that needed to be migrated into Teamcenter. I suspect that many of the issues I dealt with are pretty common and not specific to any one CAD application (or even to CAD data itself).