With PLM migrations and consolidation we are facing more and more of business objects types re-organization because of poor initial design.

What is object type?

It is a business object managed by Windchill regarding needed functionality, attributes, lifecycle states, access rights etc… By subtyping those OOTB objects it is possible to specialize them in order to be closer to business needs. We can find a lot of business objects like Part, Document, CAD Document, Change objects etc…

Types definition must be defined carefully in order to be able to manage a larger scope of PLM services across the enterprise and can result of expensive data migration if it does not respect best practices. Consolidation is more and more in the tasks list of IT Managers today because of expensive distributed Architectures (one instance for each business) and the mandatory goal today to share information across businesses.

Types organization must take into account this requirement at the beginning of a PLM project in order to avoid constraints in the future. If you have such « mistake » in your type definition it is important to redefine as soon as possible a good organization : everyday some new data will be created with the defined type

These common errors could be found:

  • An instantiable standard Windchill type with  business sub-types
  • Some new attributes on Standard types
  • A types organization without any definition of the enterprise business/product lines


As an example, if we are considering a common mistake today on WTDocument. In the AS-IS situation we can find a WTDocument not instantiable (it means that we can’t create directly a WTDocument) with new attributes. Most of the time, it is coming from a bad design without the ability to add common attributes for all defined sub-types, but we are happy… it is not instantiable 🙂 If it is, and some standard WTDocument have been created… a migration is needed 🙁

So, in order to define a better situation : it is always interesting to define a « Corporate type » before defining sub-type. When I was developer it was a Golden rule when extending a business class.. but now with less dev… it seems that we have less golden rules… But the result is the same !

Now it is possible to define intermediate types regarding your company’s organization, with the idea in mind that in the future, your data will be consolidated. At the end, the result in the database is exactly the same as the OOTB product is managing links between the instantiate business objects and his attributes (good idea 🙂 ). So migration is not needed in order to have a safer situation.


Take some times to define a robust types organization with product Experts, it will be more safe for future migrations and consolidations. It will be also more efficient for access rights management and can reduce some strange customization…

I’m just sharing my PLM point of view… what is yours?

Eve - Luc Boucher - PLM Expert