Upgrade in place Navigate 9.3 to 9.6.

[avillanueva]

Planning a system upgrade with Windchill 12 to 13 as well. Looking to see who has been down this road ahead of me and to share feedback. Specifically these questions:

1. Will Navigate 9.6 work with Windchill 12.0.2 CPS8? Or will it fail since CPS is not current? If it does work, it would be great since I do not need to upgrade both at the same time.

2. Does upgrade in place alter or update the database? Just need to know in rehearsals if DB has to be reset as well. 

3. Will any custom apps be an issue? I have a few in there. Just checking if there are any special concerns here.

[slangley]

Hi @avillanueva 

I've reached out to the Navigate team to see if they can answer your questions, but in terms of compatibility between Navigate and Windchill, I'm not sure Windchill 12.0.2 CPS8 is supported per the Release Advisor.  Hopefully, the Navigate team will be able to confirm.

Regards.

--Sharon

[avillanueva]

Thanks. I did see Release Advisor. There is supported and will not function. In this case, I am just looking to confirm the latter since the time window is short until we complete Windchill upgrade but it makes project planning a whole lot easier. 

[barko · Accepted solution]

1. Will Navigate 9.6 work with Windchill 12.0.2 CPS8? Or will it fail since CPS is not current? If it does work, it would be great since I do not need to upgrade both at the same time.

Navigate 9.6 is not supported with Windchill 12.0.2.8. The CPS at the lowest supported level usually contains code changes necessary for Navigate to function with Windchill. The lowest supported CPS for Windchill 12.0.2 is CPS 20 (Windchill 12.0.2.20).

2. Does upgrade in place alter or update the database? Just need to know in rehearsals if DB has to be reset as well. 

               Yes. The new Navigate extensions and metadata will be written to the database. A database backup prior to rehearsal is recommended.

3. Will any custom apps be an issue? I have a few in there. Just checking if there are any special concerns here.

               In Navigate 9.5.0 services in the Odata connector were classified as Public, Private, or Restricted. This caused some issues with some customizations that used OOTB services that could no longer be accessed. This caused so many problems with customer customizations that the classifications were removed in Navigate 9.5.4. Be aware of this if you decide to go to Navigate 9.5.0 for any reason. The classifications are not present in Navigate 9.6.0.

               With each release of Navigate some PTC Java methods are updated. If customizations use methods that were updated the customizations may need editing to work again. An example of the changes is a change in the syntax of the method, which will require a corresponding update in the customization. Changes are documented in the PTC javadocs. This is very specific to the details in your customizations, and may be minor or major depending on what methods or services you have reused.

[avillanueva]

Considering that I am moving to Windchill 13.0.2, I guess that means changes need to be made in parallel. New target system for Windchill like normal but I would have to rehearse on a clone of Navigate which makes upgrade in place pointless. Might as well clone it, upgrade the clone and test with WC 13 including custom apps, get those fixed if needed and then join with production WC 13 when its ready.

[barko]

There is no viable rehost method for Navigate like there is for Windchill, but a VM clone should function for rehearsal because it retains the FQDN and hard-coded references to it. I think it may have an issue replacing the previous VM in Active Directory because the GUID may change. Talk to an Active Directory Administrator to be sure.

It appears to me that the surest way to proceed is to create a new VM and join the AD domain. Then do a fresh install of 9.3 on the new VM, restore the database from a backup of the original 9.3, and import the configuration and customizations from the original 9.3. Check that everything works as expected, then upgrade the newly installed 9.3. You can follow that procedure as many times as you feel necessary for rehearsal and then join PROD.

[avillanueva]

I was able to get a working test instance (clone) of 9.3 and linked that up to my clone of Windchill. It was a slog but I was able to alter all the hostname locations to bring it up as "-test". I might be able to make use of that system to rehearse on. Agree, there should be better documents procedures for things like this.

[CP_9153795]

@avillanueva  -  Similar situation with upgrading Windchill (12.1 --> 13.1) and Thingworx  Navigate (9.3 --> 9.6) .. Any suggestions or notes on cloning Thingworx  would be great. Thanks

[slangley]

Hi @avillanueva and @CP_9153795.

Cloning ThingWorx is a relatively easy task.  Here's the process I usually follow:

1. Install a clean instance of ThingWorx--I recommend using the ThingWorx installer.  That means you'll need to create a new db instance  and you'll need to install ThingWorx on a separate VM/server--we don't support multiple copies of ThingWorx running on the same machine.  Try to make sure you're installing the same version of java, db version, o/s, etc. to truly "clone" the original and avoid introducing any new variables. 
2. Once installed, start the service and validate the new version is up and running successfully before proceeding.
3. Create another db and restore from a backup taken of the source db.
4. Stop the ThingWorx service on the new instance installed in step 1.
5. Update platform-settings.json to point to the newly created db copy from step 3.
6. Copy ThingWorxFoundation\ThingworxPlatform\keystore-password and ThingWorxFoundation\ThingworxStorage\keystore.pfx from the source system to the target.  Note: failure to do this can result in ThingWorx failing to start.
7. Restart Tomcat and validate.

By doing it this way, it isn't necessary to install extensions or make any config changes as they already exist in the db.  However, you will need to do a comparison of the files located in the sub-folders under ThingworxStorage and copy over anything that is needed, such as exports and repositories.  Also check for any manual updates that exist on the source instance in the files located in the esapi subfolder.

A word of caution....if you are trying to clone a production instance, you will need to exercise caution, as any running timers and schedulers could compromise production data.  For example, are there any services running to retrieve data from external sources that could get consumed into the wrong ThingWorx instance?  It is recommended that the new system be isolated on the network to allow for timers and schedulers to be shut down until updates can be completed to avoid disrupting the production environment.  A solid plan needs to be devised before starting this activity to identify integrations and assess the risk and mitigation around those risks.

Another quicker way is to actually create a clone via a VM snapshot and use that to spin up a new VM.  If the db is on a different VM/server than ThingWorx (recommended config), you'll need to follow steps 3 - 7 above to create a copy of the db and point the ThingWorx instance on the new VM appropriately.   You will also have to change the hostname/IP of the VM since it is a pure clone of the original.  Again, if it is a production instance, you will need to take care to ensure no integrations are running that will compromise production data.

Regards.

--Sharon

[slangley]

Hi @avillanueva.

If you feel your question has been answered, please mark the appropriate response as the Accepted Solution for the benefit of others in the community.

Regards.

--Sharon