≡ Menu

8 Questions to ask Before Starting a TC CAD Migration

NX Logo
Share the knowledge

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.

Native CAD Data

How Much Raw Data is There?

If you only have 1,000 native files then you might as well migrate everything except obvious junk like bobs_doghouse_plans.prt, and you’re probably fine using the standard import tools that come with NX. If you have 1,000,000 files, you might want to spend some time thinking about what you really need to have in Teamcenter and to what extent you can automate the migration process with custom tools.

How Clean is your Raw Data?

In a previous post I discussed the types of problems you may see with native CAD data. Some of you have file systems that were essentially uncontrolled and now look like the aftermath of a party at Delta Tau Chi house. At the other end of the spectrum are those companies who have systems in place that kept your native file systems neat and tidy. I’ve seen both. Where you fall in that continuum will shape your migration strategy.


How Complicated is your Teamcenter Data Model?

If all CAD data is stored under a single item of type, My_Item, you really can’t make any mistakes storing data as the wrong item type. If you have two types, My_Part and My_Drawing, it’s not impossible to make a mistake, but it’s probably pretty difficult to do and obvious when it happens. If you have My_Part, My_Drawing, My_Library_Part, My_Tooling_Part, My_Special_Part, My_Concept_Part, and My_Gal_Friday_Part, you’re probably going to have some problems — especially if you’re depending on users to manually select the correct item type. Sooner or later they’ll migrate a part file as a My_Part when it really should have been a My_Special_Part. And by the way, Siemens doesn’t support changing the item type of an existing item.

With a simple data model you can more easily leave assigning item type up to a user. With a complicated data model you’ll want to consider creating some automated tools to do it for them, perhaps by matching the file name against a regular expressions to see which numbering pattern the files uses, or by submitting the file name to some other system of record which can make the proper assignation.

How much Design History do you need?

Do you only need the latest revision? Latest released plus current working? All released revisions? Every revision ever created, released or not?

The obvious effect of migrating more revisions into Teamcenter is that you will spend more time moving bytes of data — in my experience the actual copying of the data from the native OS to Teamcenter’s volume servers is the most time consuming.

Less obvious is that you’ll probably end up migrating revisions out of order unless you’re very careful. If it bothers you to have your revisions ordered C-D-B-A, by date created, instead of A-B-C-D you’ll either want to spend time making sure that doesn’t happen or decide to clean it up after the parts migrate, perhaps by editing their date created attribute to match when they were created on the OS, not when they were migrated.

[box type=”note” style=”rounded” border=”full”]If you think it should be easy to migrate things in order, consider what happens when you migrate two assemblies that use different revisions of the same component. The first assembly migrated uses rev D and the second uses rev A. Presto, the component has had its revisions migrated out of order[/box]

Will you Keep the Precise Assembly Structure?

Some of us have configuration rules that say to always use the latest available revision of each part in an assembly. If that’s the case, then you can argue that only the latest revision needs to be migrated. This means less data to move, however it also means that assemblies may have to be updated to fix things like broken mating conditions or wave relationships.

Others have more complex effectivity rules that require them to maintain the exact structure, including revision, of their assemblies. This means more revisions need to be migrated. Even if you decide to only migrate the latest revision of certain top assemblies, different top assemblies may currently reference different revisions of the same component.

Performing the Migration

Centralized or Distributed Migration?

Will you have a dedicated team (or user) do all the migrations, or will you spread the work amongst the user community — giving each project team the task of migrating their own data, for example?

A centralized strategy has the advantage of economies of scale and being able to perform whole system analysis. For example, if you know that you are the only one doing migrations know precisely what’s been migrated and what has not, then you can make decisions easier than someone who may not be able to see all of the data nor be certain what someone else is doing at the same time.

The distributed approach has the advantage of spreading the workload around so no one user is dedicating a significant amount of time on migrations.

Personally, I prefer the centralized approach for complicated migrations involving messy native data and a complicated Teamcenter data model.

Vendor’s Tools or Custom?

NX has a GUI for importing data. Although it is somewhat cumbersome to use, any NX user can use it. I wouldn’t recommend it for doing any significant amount of data migration.

There are also command line tools for importing data. They are more useful for migrating large amounts of data, however they are a general tool and are not designed for your data. Of course, the advantage is that the utilities have already been developed and are supported by Siemens. However, if your migration is complicated enough you may prefer to invest in your own development effort so you have full control of the process.

Will you Fix Problem Data Before or after the CAD Migration (or ignore them)?

Unless you are very fortunate, you will have some data that will not migrate into Teamcenter correctly without some sort of intervention. That intervention could be a user fixing the data prior to migration, automated tools designed to detect and correct the problem during the migration itself, or having a process to automatically or manually correct the data after it is migrated into Teamcenter. Some of the issues I’ve seen are as follows:

Incorrect Item IDs

Typical example, the file should have been named 1234567_a.prt, but it was actually named project_x.1234567_a.prt, so the item created in Teamcenter is PROJECT_X.1234567/A.

I would at least consider fixing the data prior to migration (or design the migration to assign the correct item ID despite the incorrect file name), however, you have to be careful. What if there is both a project_x.1234567_a.prt and a 1234567_a.prt? Now it’s not so clear if you should renumber the prefixed file. For this reason I suggest waiting until the migrations are completed and then correcting what was actually migrated — perhaps only one of the two files will be migrated.

Multiple Items for same Part

One version is where each revision of a part has a different prefix: curly.1234567_a.prt, larry.1234567_b.prt, and moe.1234567_c.prt. The clean solution would be to eliminate the prefixes and migrate the files as three revisions of the same item, 1234567.

The messier version has multiple file at the same revision, 123456_a.prt and project_x.1234567_a.prt. Here you will have to do some additional digging to really understand what’s going on.

I think it’s worth trying to minimize this problem by cleaning the data prior to migration, but unrealistic to think you’ll completely defend against it unless you have very little data to migrate. You should plan on having duplicated items that you either decide to live with it or clean it up later.

Inter-part Relationships

If don’t preserve the precise assembly structures of parts you will migrate assemblies with different revisions of components than what they were saved with, which will mean that certain types of inter-part relationships will be out of date. If your data is NX, the following are some of the things that could need updating:

  • Mating Conditions and Assembly Constraints
  • Component positioning
  • WAVE Data
  • Promotions
  • Inter-part expressions
  • Drawing Graphics

If this applies to you, there really isn’t anything you can do prior to migration other than to manually update and refile the assemblies. You’re better off waiting until the migrations are complete and then updating the assemblies as the need to work with them arises.

Reordering Revisions

As I mentioned above, if you migrate multiple revisions of a single part you will have to either take care when migrating to migrate the revisions in order, or post-process the revisions when the migration is complete to modify their creation dates so that they are in the correct order.

  • Anonymous

    Hi. I’ve done some migrations and agree in what you say.
    One question. At the end under “Reordering Revisions” you say “modify their creation date”.
    How do you do that?

    • http://plmdojo.com Scott Pigman

      Hi, Totte. You have to write some ITK code. ITK_set_bypass() and AOM_set_value_date() are the critical functions.

  • Anonymous

    Ok, thanks.
    That explains why I didn’t find any way to do this using the GUI 😉

  • Anonymous

    Here a tool that will help you to determine if all of your data made it over successfully including PMI, GDT and assemblies.  http://info.kubotekusa.com/validatecad/products-and-services-0/validation-tool-server/

    • http://plmdojo.com Scott Pigman

      Last I knew kubotek’s validation tool wasn’t integrated with Teamcenter. Ideally I’d be able to feed it an item ID/rev ID and a native file path and have it compare compare the two. Has that feature been implemented?

      • Ssweeney

        The teamcenter integration is in Beta now.

        • http://plmdojo.com Scott Pigman

          That is excellent news. Let us know when it’s ready for the world.

  • Mauro Conceicao

    Scott, very usefull information. Have you had experience mgrating CAD data from Catia V5?

    • http://plmdojo.com Scott Pigman

      Sorry, no, I don’t have any experience with Catia. I hope though that many of these tips will still apply.

  • Mr Migration

    Hi all

    Since 1995, we are working in the them DataAnalysis, migration Metadata,
    migrating CAD-Data form and to Teamcenter. Therefore we set up Migration Tools
    which is supporting the migration process from the beginning (Export foreign
    systems) thru converting into other formats, upgrade metadata, importing BOM, correct
    metadata, synchronizing metadata to CAD-files, up to automated import process
    into Teamcenter

    CAD-System where we support: NX, SolidEdge, Inventor, AutoCad, Catia, ProE

    If we can help you, please

    [email protected]

  • Pingback: PLM Weekly News: September 22, 2011 - Zero Wait State()

  • Kannan Ramasamy

    HI all…..
    I want to learn how to write a dll , extention and SOA for T 8.3 and TC 9.1..
    suggest me some good links to learn the same…

    • http://plmdojo.com/ Scott Pigman

      Hi, you’re off topic – please be more mindful of the post you’re commenting on in the future.

      Go to the documentation area of GTAC

      click teamcenter

      log in with GTAC webkey

      pick the version you’re working with

      Download the PDFs for the Server Customization Programmer’s Guide, The Business Modeler IDE guide and the Services Guide.

  • Antony George

    Hello Scott,
    Great article about TC CAD migrations. I was working as a Teamcenter developer and now I have come into an admin and support role. I am a total newbie to CAD data and legacy data migrations to TC and to rub salt into my wound my Organization uses Pro-E, AutoCad and Solidworks at different sites around the globe with each site using the CAD tool they prefer. Now it is mine and the teams responsibility to migrate the entire data into Teamcenter. And to make matters worse each of the four sites contains around 60000 files. Any tips regarding how my approach must be would be of great help!
    Thanks & Regards,
    Antony George.

Optimization WordPress Plugins & Solutions by W3 EDGE