Community Tip - When posting, your subject should be specific and summarize your question. Here are some additional tips on asking a great question. X
Version: Windchill 12.0
Use Case: We're looking at a one time migration from one 11.0 system to a new 12.0.2 system, EPMdocuments only
Description:
Does anyone have an prior experience on using this for this kind of use case?
There are multiple options but I'm most curious about the Windchill import/export of containers option.
I have a theory it will fail if there is CAD data used across multiple containers but nothing really addresses that in the PTC support information.
I know PLM Connector and Packages are other options, If you have experience with using Packages for this, I welcome any input on that as well.
Mostly trying to get a feel for how well these worked out(or not) for others.
Solved! Go to Solution.
Hi @slapha
The context import/export is good for some small projects and similar systems also there could be compatibility problem with the target system.
Also there is time consuming preparation. You can use it easily for several objects. Nearly always you would need to redefine exported zip and prepare this import pack for target system. Especially the XML files that contain database information.
I did it several times and I always ended with solving issues step by step, one by one.
Problem with revision identification, lifecycle identification, dtd compatibility between version. ufid identification of any object.
ufid has to be unique, but if the system already has some data, it is impossible to import. You have to change it in the source files.
There are really many issues there that can pop up 😄 and you would not expect it.
Sometimes it is not logical why the error is shown.
Here is an example snap of the import xml file from the exported zip
You could see that the domain information is there so it has to be also solved.
If you migrate to the new system, there are not so many issues with UFID and it is easier. Also I recommend to use same domain
This is my experience that I would say yes it is possible to use it, but first you have to identify all issues that should be solved on a small package of objects.
Then you can use it. but keep in mind, you can no export all in one click. If you have filevaults 1000 GB huge, then you have to split the export to a smaller packs. My experience is that more then 20GB can case some zippacking/downloading issues.
I believe that there are better ways how to migrate data. For example Windchill packages are better then context export/import where you can set the target system.. Sure you have to know how to configure it.
.
PetrH
Hi,
WBM is the tailored PTC tool for this. Hope you are using it for this.
Do you face issues in extraction or stating or loading? Hope your Target system is up and running.
Cheers
Hari
Not really an option for us.
Sorry, I know this isn't the functionality you are explicitly asking about, but it can do partial data migrations across different source/target Windchill versions.
Software Factory migrates data using their in-house tools WT-Merge and WT-Validate. Their solution is older than PTC's Bulk Migrator and isn't tied to DB level migration. So, your 11.0 system doesn't have to be upgrade to migrate the data into the 12.0.2 target.
Last year we used Software Factory to merge three Windchill systems (10.0, 10.2, and 12.1). It takes time to do it right, but it went smoothly. Kicking off a migration from PDM Essentials 12.0 to PDMLink 13.0 this month. These are all content moves, not container specific. But, if you can provide a list of what needs to be migrated, they can probably do it.
WBM is only available to VARs or PTC. Customers are not entitled to it... @slapha - good to see you around. What is the complexity / type of content in the current system that you don't want to migrate to the new system? Just documents? wtparts? Change objects etc?
Short term, just CAD. Mostly seeing what success/horror stories people have. We have the options to try and I think we have an order of attempt, just want to know what lies ahead.
Absolute death, destruction & bedlam awaits... Or it could be rainbows and unicorns. There might also be some creative options like rehosting and taking the rehosted system, delete in the order of Parents > children non required objects. (CN's,>CR's> Prob R's,>Prom R's,>Docs)
If you have WTparts and don't want WTparts that would get a bit more tricky I would think.
Hi @slapha
The context import/export is good for some small projects and similar systems also there could be compatibility problem with the target system.
Also there is time consuming preparation. You can use it easily for several objects. Nearly always you would need to redefine exported zip and prepare this import pack for target system. Especially the XML files that contain database information.
I did it several times and I always ended with solving issues step by step, one by one.
Problem with revision identification, lifecycle identification, dtd compatibility between version. ufid identification of any object.
ufid has to be unique, but if the system already has some data, it is impossible to import. You have to change it in the source files.
There are really many issues there that can pop up 😄 and you would not expect it.
Sometimes it is not logical why the error is shown.
Here is an example snap of the import xml file from the exported zip
You could see that the domain information is there so it has to be also solved.
If you migrate to the new system, there are not so many issues with UFID and it is easier. Also I recommend to use same domain
This is my experience that I would say yes it is possible to use it, but first you have to identify all issues that should be solved on a small package of objects.
Then you can use it. but keep in mind, you can no export all in one click. If you have filevaults 1000 GB huge, then you have to split the export to a smaller packs. My experience is that more then 20GB can case some zippacking/downloading issues.
I believe that there are better ways how to migrate data. For example Windchill packages are better then context export/import where you can set the target system.. Sure you have to know how to configure it.
.
PetrH
Thank you for the detailed reply.