Success Path
Everything you need to know to upgrade your ThingWorx Platform

Establish Testing Environment

Create a test environment that is a replica of production so that testing and validation are completed accurately before the Go-Live upgrade on the Production server. This helps you avoid any significant setbacks when moving to production.

Backup ThingWorx

You want your test environment to be as close to your production instance as possible. ThingWorx related backups can be executed at both the datastore level and ThingWorx application level. Refer to the ThingWorx Backup and Recovery Planning guide to start preparing for backups and refer to the original vendor documentation for further details, including the following:


Watch our Expert Session on ThingWorx Backup and Recovery for best practices around:

  • Strategy and tools for ThingWorx application backups
  • Backup terminology and concepts
  • Drivers to define a backup strategy
  • Tips for executing backup in a ThingWorx instance: Tomcat, certificates, configuration and file system data, application-specific files, database

To learn more about application-level backups such as Import/Export of entities and data from the platform, review How to Import/Export Entities and Data in ThingWorx.

Review Best Practices for ThingWorx Backups, Replication, and Migration to learn more about the topic.

In case your current installation involves other complex customizations, functionalities, and installations such as SSO, High Availability, or any third-party software/hardware:

  • Take necessary backups of all data and configuration files
  • Contact PTC Technical Support or search the PTC Knowledge Base for any query

Ensure each resource working on this objective has access to the right environments and knows how to contact PTC Technical Support.

If you followed a DevOps process, your work should already be backed up. DevOps' critical portion is setting a Source Control Solution such as Solution Central, Git, or SVN that helps you manage code repositories. Your developers should access and back up the code as they collaborate to build your application. If your organization lacks an official DevOps process, take a look at Establish DevOps Practices for ThingWorx. A PTC expert helps your team understand how to implement ThingWorx configuration management and coding and naming standards. We work with you to find the best solution to use your current source code control systems or recommend a new one and promote code from development to test to production.

Recommended Resources

Create a Testing Environment

Create a test environment using your most recent ThingWorx backup which should be replica of production.

Make sure you know:

  • Which environments have been configured and who has access to them
  • Release numbers & software versions
    • Evaluate product compatibility matrices and PTC product calendar
  • Naming conventions
  • Hardware requirements (Memory, Storage & CPU cores) in production
  • The capacity you need to create an environment
  • How to move your backed-up code files and data files to this test server

Document your work and sequence of events followed through this process.

Be sure to contact PTC Technical Support with any questions regarding downloading software, installation, documentation, or moving code & data files to the server.

Recommended Resources

Validate the Testing Tools and Processes

After the server has been prepared, the very first step is to verify licenses and functionalities.

For license

  • Login to Composer
  • Navigate to Monitoring -> Subsystems -> Licensing Subsystem Settings
  • In case of any issues follow these steps or reach out to PTC Technical Support

Recommended Resources

PTC recommends incorporating three levels of testing into your DevOps:

  • Unit testing: where you test each component independently to ensure they're operating as expected, like creating test services and executing through REST API's or manually
  • System testing: testing the features and functionality of a collection of components
  • User acceptance testing (UAT): bringing in select end-users to ensure the application is meeting their needs

Move forward through the creation of test plans, test scripts, and tools to validate. Verify they are available in an accessible location with required access. If necessary, go through a trial run to ensure nothing gets stuck.

Ensure you're testing the right items. Run scripts and tools through iterations and record test results. Use assertions as well. Test plans should include any non-ThingWorx or third-party software as well.

Recommended Resources

Identify Resources Required to Validate

Identify your project team with the right capacity to validate the software on the test environment. Ensure you have the right mix of people to test the software thoroughly and completely.

Resources identified could be:

  • Internal team members who have both ThingWorx admin access as well as access to mashups/apps
  • External clients, partners, stakeholders & end users having access to only mashups applications but no access to ThingWorx composer & no admin access
  • Skills-based resources for automated & unit testing, preparing and executing test scripts & tools, creating test plans and validation criteria, Java, database to check for data flow and integrity, and managing source control repositories.
  • Other resources may be required as per the involvement of any non-ThingWorx or any third-party software.

Ensure the resources you identified as testers can access the testing environment, test scripts, tools, test plans, and all processes. They should have proper rights & permissions to run and execute those services and tools as well.

Ensure they are available to begin testing when needed, get approvals from their managers if needed.

Test plans and validation criteria as per user's test limit should be made available to users, if possible. While testing, they should record the results and preserve for prospects.

Turn off Non-ThingWorx Software

ThingWorx should run correctly without any failure while turning off the non-ThingWorx software in parallel. ThingWorx should not go down, failing any dependency checks while turning off any non-ThingWorx software.

Non-ThingWorx software could include:

  • Network layers, firewalls, and proxies
  • External databases
  • ThingWorx connected to external apps via connectors
  • External frameworks (Java-based or testing)
  • Load balancers
  • Source control systems like SVN or Git
  • Any third-party application

Try making ThingWorx software less dependent on any external software/applications. Make sure ThingWorx is up and running even if any non-ThingWorx software in the environment goes down. If their dependency cannot be avoided, that should be well documented and communicated among team members. Testing around these areas should be well performed and documented. These test plans should be sent to resources allocated for this task. If there are several dependent non-ThingWorx software or third-party software, then test suites/cases should cover all various possible combinations of dependency checks.

  • Monitor the impact and behavior of ThingWorx software while other non-ThingWorx software is turned off. Closely monitor ThingWorx application logs for some time at regular intervals for any issues/errors. Ensure that data flow, connectivity, and functionalities are hampered.
  • Run the test suites, scripts, and tools while turning both off and on the non-ThingWorx software and record the results. Resources should be evaluating the results against the validation criteria mentioned above. Any criticality, unusual behavior observed, or some observed issue we cannot avoid, alert the project members.
  • Ensure all dependencies are well placed, checked, and documented well enough.
  • Document and understand the effects of dependent non-ThingWorx software going down:
    • Downtimes
    • Preventive measures
    • Urgencies
    • End-user effects
    • Backup plans
    • Cost
    • Data loss
  • The team should always have a proper backup plan or an alternate plan to ensure dependent non-ThingWorx software gets up and running ASAP to minimize the loss.
  • Document and understand the effects of non-dependent non-ThingWorx software going down, i.e. the amount of data loss due to downtimes & cost. Prepare a backup plan or alternative plan to ensure non-ThingWorx software gets up and running ASAP to minimize the loss.
  • Backups and recovery paths should always be on top of mind.
  • In case of urgencies or any critical issues, resources should contact PTC Technical Support.

Once test resources feel that software is successfully deployed and the validation criteria is showing satisfactory results, inform project members/stakeholders and provide a green light for Go-Live.

Recommended Resources

Did you find this helpful?



Find step-by-step instructions and information about using the ThingWorx Platform and ThingWorx applications in the Help Centers.

PTC Community

Visit the PTC IoT Community to get product assistance, share ideas, and browse information about using ThingWorx.

Technical Support

Log a case with eSupport using your Service Contract Number. Don't have it? Ask the Community.

Contact Us

Have a question? Submit your contact information and we’ll reach out within 1 business day. You’re never obligated to purchase or commit.