Evaluate Requirements to Upgrade

Before you upgrade ThingWorx, you need to understand what is standard ThingWorx and what your team has customized. Your customizations should have been documented by your developer when they were initially implemented. With version 9+, there is no widget or extension depreciation from version 8.5. Please review previous versions of ThingWorx to better understand the possible depreciation of widgets or extensions.

If you have a backlog for ThingWorx, review the line items in the log before you upgrade. There may be items you move around based on the new features and functionality. At this time, determine if any work needs to be done before and after the upgrade. We do not recommend making changes during the upgrade.

Begin to mark new backlog items based on the features and functionality you plan to implement after completing the upgrade.

Whether you use ThingWorx in your manufacturing plants or smart products, it is essential to think about each instance’s unique activities. Determining these activities helps you decide when to upgrade and how to test a specific instance.

It would be best if you also determine what activities should be completed while ThingWorx is unavailable. For example, if ThingWorx runs your factory’s machines, you need to determine if the downtime is acceptable or if there needs to be a manual intervention. Also, be mindful of:

• Number of users on the instance
• Critical company events
• The amount of data on each instance
• The cost associated with each instance

There are several more factors to consider when planning your upgrade.

Understanding the downtime required for each instance is critical to a smooth upgrade. Be sure to evaluate each instance’s needs and compare them against your test upgrade when the time comes.

Now that you have evaluated each of your production instances, you must now determine the right time to complete the upgrade. It may not be possible to upgrade each of your instances simultaneously because of the previously determined unique activities. Hence plan your upgrade order for each site accordingly.

It is best to complete the upgrade during a slow time of year, such as late December.

You also want to consider the other PTC products you own and when they need to be upgraded. You can review the PTC Product Calendar here.

Before you can upgrade to the latest and greatest ThingWorx has to offer, make sure you know your path to upgrade. Check out this article on how to find the software compatibility matrix for your specific release.

When preparing for an upgrade, it is essential to think about your connections to other ThingWorx and PTC products. Please take a close look at the changes and constraints from your current version to 9+, where it applies to other ThingWorx products such as ThingWorx Analytics and ThingWorx Flow.

Key considerations include:

• Evaluate each products’ roadmap release dates, end of support, and end of life information. Please find this on our PTC Product Calendar.
• Find & review the Software Compatibility Matrices for Creo-Windchill products

The features available in ThingWorx 9+ can help improve your ThingWorx’s security. There is a change in the way audit data is stored in ThingWorx. Your current set up for logging data will still be available and still the default in the new release. You will need to actively change the configuration and update each of your customizations that use audit data. Also, you will need to plan to transfer your existing audit data to the new implementation.

The audit subsystem is intended to provide the information you need to answer the following questions:

• Do we meet compliance requirements?
• What has a rogue employee done in the system?
• Who made what changes and when?

A new feature available in ThingWorx 9.0 is Thing Groups. Thing Groups are a referenceable entity type in ThingWorx that allow for Things and Thing Groups as its members. In addition to ThingWorx’s current permissions model, Thing Groups provide ThingWorx administrators the ability to manage at scale exposure of Things to only those that require access. These are the following prominent use cases for Thing Groups:

• Visibility permission management at scale - You can group Things so that only specified user groups or users can see them. Thing Groups allow for visibility permission delegation. This visibility permission delegation is enabled in the User Management Subsystem. Visibility permissions delegation allows users to set the org units (and corresponding users and user groups) on Thing Groups and have that visibility setting delegated to the Things and Thing Groups (as well as any level of grandchildren) that are members of the Thing Group in which the visibility permissions were set.

• Thing Groups as a building block for mashups and other applications - Application developers can leverage Thing Groups to visualize hierarchies or scope custom workflows to a specified group of Thing.

• ThingWorx SDKs offer secure and robust SSL/TLS support by providing support for the latest, long term support version of OpenSSL

The most common ways to group Things are by regions, customers, specific locations, and model number. You can learn more about Thing Groups here.

If you plan to implement High Availability Active-Active Clustering, this is a significant change to your infrastructure. If you would like to learn more about this new functionality, take a look at the Principles of ThingWorx Active-Active Clustering. This service takes you through the best practices for configuring your high availability.

Review your previously documented plan and determine the difference. Here are a few topics to consider as you create your infrastructure architecture plan: 

• Availability
• Will ThingWorx or applications need to be available at all times? 
• Is downtime acceptable? Consider both planned downtime (upgrades, updates, maintenance) and unplanned (failures, outages).
• Security
• How will security requirements affect your infrastructure?
• How will security change over time?
• Scalability
• How will High Availability Active-Active Clustering improve ThingWorx’s ability to scale my devices and instances?
• Do we have the right amount of server for our scaling needs?
• What other changes do I have to make when configuring High Availability?

When ready, document your final changes and share them with the project team.

When upgrading to a newer version of ThingWorx, administrators have two options for getting new features and enhancements into existing landscapes: in-place upgrades and migrations. Generally, in-place upgrades are applicable when upgrading to the same persistence provider and don’t require import data/entries after installing ThingWorx. Migrating includes more steps since you must export data and entities then import those entities and data into the new version of ThingWorx. And this is majorly applicable when upgrading to different persistence provider.