Feasible Windchill deployment and upgrade concept

[tbauer-2]

The more comprehensive the Windchill solutions are for our customers, the larger the scope and number of configurations and customizings will be. At the same time, the number of test and development systems increases.
Today it is extremely time-consuming and error-prone to maintain these systems at a uniform configuration and customizing level. Here a Windchill own transport system would be very useful, with which customizings and configurations can be synchronized.
Furthermore, an update concept for large Windchill releases is missing. An update from e.g. 11.0 to 11.1 means a new installation with subsequent manual transfer of the configurations and customizings. Also here at least a Windchill transport system would be very helpful.

[Liam]

I would add that the documentation for these procedures should be thoroughly tested. This is currently a major defect, costing person weeks of time to resolve.

[BenLoosli]

It is very hard to do a rehost/upgrade without scouring multiple PTC documents, CS articles and installation guides.

One of the statements that catches my eye in the installation manual is to create your own set of instructions. Since you have to pull bits and pieces together, you have to document everything in your own consolidation document of what is needed at each step.

When I did an install last fall, I documented the steps, including any customizations and preference settings in my own installation guide. It included ACL setting information, profiles, OIR settings, workflows and lifecycles. Very time consuming to build a new system from scratch.

Rehosts are only a little easier, but still require a document to capture everything you need to do to make a successful rehost. Using the rehost guide alone is not enough and if anyone can do a rehost straight from the rehost guide in one shot, I'd like to see how.

[TomU]

I'm trying to do this right now and it's very difficult.  It would be much simpler if everything was just stored in the database (since that migrates automatically.)  Unfortunately, many of the settings are buried in properties files (or other types of files), and there is no easy way to identify which ones have been modified since the original installation.  I try to document any changes I make to the system, but the probability of missing something during an upgrade is very high.  To make it even more challenging, each new release adds new properties, eliminates others, and changes the default values of still others.  Trying to compare all these and then figure out which ones still need to change is nearly impossible.  I'm sure large companies with teams of developers have better ways of dealing with this, but for a small company with one person who handles all this (me), it's quite a challenge and really slows down the rate we can move to new releases.

[STEVEG]

@TomU "it's quite a challenge and really slows down the rate we can move to new releases."

This is exactly right!