Before I begin, I am wondering that I can see a lot of hits for his topic, but no questions being asked no this topic. Appreciate you inputs/questions here and I will try my level best to address them.
WBM tool touches almost each and every feature of Windchill. This is one of the latest launched tools by PTC and is used to Migrate from other products to Windchill. It can be also used to migrate from Windchill to Windchill, but honestly speaking, Upgrade Manager works better for Windchill to Windchill upgrade, unless a special case where you might want to upgrade from multiple Windchills to a single Windchill or old Windchill version to an existing Production Windchill.
WBM tool touches almost each and every feature of Windchill. This is one of the latest launched tools by PTC and is used to Migrate from other products to Windchill. It can be also used to migrate from Windchill to Windchill, but honestly speaking, Upgrade Manager works better for Windchill to Windchill upgrade, unless a special case where you might want to upgrade from multiple Windchills to a single Windchill or old Windchill version to an existing Production Windchill.
Recently, I was involved in the WBM project where we
migrated to Windchill from another product. The key behind a successful WBM
migration project is intensive planning and source data Generation. If you can
generate Meta-data of your existing data it comes in very handy. If you can
create a meta data which can be seen in the form of a DB table, nothing like
it.
So as I was saying, WBM project is planning/research intensive. You
need to understand clearly what you have in your source and what do you need to
see in Windchill. Sort out all the primary type of objects you have in your
source system i.e CAD Docs/drawings, Documents. These objects can be stored on
a hard drive. Next are the logical objects like WTParts, CNs etc. These act as
primary objects in Windchill but are logical. A non-Windchill system will have
primary objects but not necessarily have logical objects with the same mapping as
Windchill.
This brings us to the next important step. With what
meta-data you have from the source system you should be able to map it to the
Windchill objects in the form of Windchill object’s attributes(IBAs). Once you define a clear attribute map, you
can understand which attributes from Windchill are going empty and what needs
to defined in them.
Once you have this attribute map, you can go back to
Windchill and create all the data that is needed to load the source system
data. This can include new Object Subtypes, Users,Products, series etc. This is a
non-WBM step and preferred if you can use Windchill Load utility or any other
OOTB functionality for all this stuff.
Upon installing WBM software on the Target Windchill, you
need to study the entire Staging database to understand what is missing in the
Staging DB tables e.g. attributes of objects, extra columns. You need to check
if all the attributes for a given object can be loaded using WBM or not, If yes
then which table satisfies the need of which table.
Based on these tables you create a table design in which you
have to mold the source data so that it can be imported into these tables.
Hence it is essential if you can modify your source data into Meta-Data. WBM
4.0 comes with the ease of migrating directly from a Hard Disk. But that’s only
for physical objects.
Once you define your physical and logical objects you need
to understand and define the links between multiple objects types e.g.
EPMBuildRule is used to connect an EPMDoc to a WTPart, Includedin2 is used to
connect a Change Notice with its Change Task.
This is the tricky part and hence you need an intensive
mapping and more importantly understanding of how you define your source system
data.
You cannot just load all the data to WBM and run the loaders
all together. The is standard sequence of loading objects to Windchill and
totally dependent on what objects you have in hand.
e.g. The first objects always to go in are the EPMDocs and WTDocs
since they can survive in Windchill as standalone objects.
I cannot load a Reference link object if there is no corresponding
Drawing to it. Hence, we usually will load the physical objects followed by the
logical objects followed by the link objects.
WBM is a new tool and you can hit a lot of bumps when
working on it and not a lot of data is available on the PTC knowledge base to
resolve them. Hence pilot is always recommended so that you can carry out POCs
for the different objects for checking data integrity and successful migration
with the sourc data in hand.
The sequential progress of a WBM projects looks something
like below
