Migration Conflict Resolution questions

[ptc-141591]

I'm migrating three 3.4 databases into a single 9.1 install. I've migrated the first 3.4 and am now getting conflicts (as expected) with the second 3.4 system migration.

I have the 3 Rename csv files created by the DocResume step. Page 6-11 in the Migration Guide says to edit the Rename_ProI.csv file and change one or the other of the object pairs. It says to save the changes, but never says what to do with the file. Is it automagically processed the next time DocResume is run? If not, how are these changes applied, especially if I want to rename on the 3.4 side. The other 2 Rename csv files are processed by the MassRename option in ildataloader, but no mention of what happens to the Rename_ProI.csv.

Also, if a duplicate object is in 2 different folders on the 3.4 systems and I want to use the Duplicate Object Manager to merge them, do I wind up with 9.1 iterations in different locations or is the target system folder used for all iterations?

I'm assuming I need to rename the objects I don't want merged, then rerun DocResume, then run Duplicate Object Manager to merge the remaining objects. Is this the correct procedure or am I off track?

Thanks

[patrick.chin1]

you should really look into this refined solution with new indexes for identifying EPM based on

• Auto Association of CAD to Part will be based on synchronizing CAD and WTPart number only. If there is no respective Part number, there will not be an auto creation of Parts
• Object uniqueness based on number, authoring tool, type and organization id (Pro/I instance)
• Filename uniqueness based on filename, authoring tool, and organization
• Subtypes of CAD documents based on authoring tool and type (ProE assembly, ProE drawing)
• Number generation is manual
• As Stored configurations will not break due to data cleansing between "duplication" of Pro/I databases.

I strongly advise not using PTC's workaround of using organization ID principal attribute as the CAD sub type, because this doesn't follow the architecture of supply management (SUMA) with Windchill.

[patrick.chin1]

There is no data cleansing required. For your Windchill install, you have to create 3 organization context/containers with their respective 3 organization ids for your 3 Pro/I databases. Once you:

• created a separate organization id and context for each Pro/I database
• applied my new indexes
• changed the preferences to remove the file extensions off the number
  • map PTC_COMMON_NAME to Windchill NAME
  • map doc_name to Windchill Number
• then migrate.

You will not require to perform data cleansing. It is very hard to determine if the objects with the same number.ext in multiple Pro/I are identical. Some cases they are completely different models and their associated parents require the original features. And if they are from different organizations, the separate organization ERP systems already have identified them as separate business objects.

This will save you tons of data cleansing time and issues that should not occur when upgrading from PTC solutions that should support ProE. The difference is that Pro/I is a file managment system and Windchill is both metadata and file management system.

I just feel sorry for customers who already spent tons of money and are stuck with just a Pro/I methodology and can't move forward with WTPart methodology.

Good luck,

Patrick

[patrick.chin1]

Here is an updated instruction document in case you already have a PDMLink system with one migrated Pro/Is and want to migrate additional Pro/I databases into separate respective Organizational Contexts tied to a separate organizational principal ID. Additionally, you can place all your configuration, start, format files in Windchill Standards Library to have you config.pro to point to. Make sure that your ProE server registry has the fully qualified name for both name and connection. this is to standardize all config.pro's for users.

[patrick.chin1]

Here is an updated slide deck of the solution with unsearchable items in a Private Project. It requires EPMDocumentMaster.DocumentNumber,EPMDocumentMaster.CADNAME and EPMDocumentMasterKey.WTKeyto be changed within the database. Again test this on a test system first. If you use the UI to RENAME, these columns would be renamed via APIs, but some items are private and not accessable by administrators.