Configuration Migration

[BF_13811900]

Version: Windchill 13.0

Use Case: I am trying to migrate the full configuration of a development instance of Windchill into a production instance on a separate server. I have identified the aspects of configuration below that I would like to bring across: 1. Attributes (Local & Global) 2. Enumerations 3. Policies 4. Object Initialization Rules 5. Object Sub-Types 6. Workflows 7. Lifecycles 8. Users 9. User Groups 10. Change Task Templates 11. Folder Structure 12. Profiles? 13. Preferences (site, organization, context, and user) 14. Config of Local Team Roles and Members Having looked into this first, I understand that it is important to import certain elements of config into my production instance first so that the other elements can be created successfully. For example, it would probably not be a good idea to import object sub-types in before importing the attributes that the sub-types make use of first. Based on this, I have decided that a good starting point would be migrating my set of preferences first as I suspect the success of importing my preferences configuration is not dependent upon other elements being imported first.

Description:

I have ran the following command from the Windchill Shell in my development environment to extract a full set of the preferences - windchill wt.preference.ExportPreferences. I been able to use this command to successfully create a file which appears to feature all of the preferences within my development instance of Windchill (this file seems to include data relating to preference definitions, categories, instances and clients. I am not entirely sure what these types of objects are used to represent so if anybody could shed light on this, that would be appreciated. I am only trying to ensure that the preferences that I have set in the GUI as a site/org/product admin on my client are copied to the prod environment so I'm not sure if all of the content in the export file is relevant to me). I have then copied this file to my production server and made use of the following command to try and complete the import - wt.preference.ImportPreferences -importfile=myexportfilename.xml. However, this fails in the shell with the following error message:

ERROR wt.preference - java.rmi.ServerRuntimeException: Server exception; nested exception is:

        java.lang.NullPointerException: Cannot invoke "java.lang.Throwable.fillInStackTrace()" because "<local18>" is null

When I check the method server log, I can see the execution of the command produced this message in the log:

ERROR wt.preference - java.rmi.ServerRuntimeException: Server exception; nested exception is:

        java.lang.NullPointerException: Cannot invoke "java.lang.Throwable.fillInStackTrace()" because "<local18>" is null

Can anybody explain why I am experiencing these issues or provide any other helpful advice?

[avillanueva]

Did anything change with any resource bundles? You might need to make sure those are loaded first. 

[BF_13811900]

I don't think I have intentionally made any changes to any resource bundles on my production server as of yet. I am not entirely familiar with what a resource bundle is. However, I think you're referring to any .properties files stored on the servers? If so, I have probably modified the OOTB .properties files in my dev environment but not on production. Are you suggesting I bring these across before trying again?

[tarik_p · Accepted solution]

@BF_13811900  This is called configuration loading from lower-env to production.

I wonder why you are still using a shell utility???

Please consider using the BAC utility, it's UI friendly and supports most of the object types you are trying to load:

Business Administrative Change Promotion

Article - CS330275 - [Knowledge Hub] Windchill PLM - Business Administrative Change Utility (BAC)

Only go with the shell utilities when it's necessary!

Tarik W.

[BF_13811900]

Hello Tarik. Thanks very much for this. I am actually partially through the "Windchill: Code & Configuration Deployment" courses on available in PTC university and they say the same as you i it is better to use the BAC utility where possible. Thanks for sending the links across. It's good to see that a lot/all of the configuration elements I am looking to migrate is supported by the BAC utility. I will go down this route. Thanks again!

[BF_13811900]

@tarik_p I've had a look at the article included in your last response and it explains that the BAC utility is suited for moving configs between "two or more different environments, not different systems which may refer to different sites (different installations). A different environment is usually a system cloned from the production and both or all are almost identical.".

I was wondering if this makes sense to you? The way in which my production environment was setup was by creating a new server and doing a brand new install on it. I wish to move my config to this new installation. We did not take a clone of the dev environment.

I am not entirely sure on what PTC considers the differences between a system/site and environment are. But, it looks like the BAC utility isn't suited to my current situation. Do you agree with my understanding?

[tarik_p]

Yes, so the BAC is meant for env to env (in general), but they don't have to be identical; you can make them identical manually and decrease discrepancies. 

The Export/Import utility has this concept of mapping because it's meant for site-to-site.

It's all about how those two systems are set up and the config type you would like to load.

There are many data loading utilities in Windchill. I recommend using the UI ones over shell unless the object type is not supported via any UI utility, but you can combine them all to achieve your business case, see the graphic in: Article - CS175236 - [Knowledge Hub] Windchill PLM - Data Loading

I have an updated version of this graphic, see Linkedin post , and I'm working on a new one for 2026 to add CCD. I may include what you said: the real difference between env and site, but as I told you, it depends on how source and target systems are set up.

For your use case, Preferences like almost all features in Windchill are tight to contexts, and it may fail if the same org or app context does not exist on the target system, needs a check!

[BF_13811900]

Thank you very much for all of this @tarik_p  - it's really helpful.