Capture Current System and Processes

Windchill deployments change over time. It is imperative that you take the time to validate for the true, current state of your instance. Your PLM support staff may already have documentation of the system’s evolution; spend some time creating or consolidating that documentation and ensure it is up to date.

This information will help you set with stakeholders and plan accordingly. Once the inventory is completed, you can confidently:

• Develop an accurate initial deployment plan
• Provide more accurate and realistic estimates for time and effort
• Identify potential pitfalls before they hinder a transition
• Set realistic expectations

A rollout should not be solely based on what items were previously purchased.  That information is useful but does not provide the full picture.  Purchased software may or may not have been implemented.  Capabilities may be implemented but not utilized.  Customizations may have been added or changed over time. Beyond those basics, this detail provides you with an overview of the current deployment’s likely performance.  Such information is critical to planning a cloud deployment that will meet/exceed stakeholder’s expectations.

Challenges with PLM are not uncommon. These challenges can come early during initial rollouts, later on when adding new capabilities, or during upgrade. To eliminate pain points and increase value, run a health check using Windchill Diagnostic Utility (WinDU). WinDU is a read-only reporting utility that reports the current state/health of the system while making no modifications.

Once WinDU has been run, evaluate the recommended changes in the report. You may also need to run the Windchill Repair Utility (WinRU), a utility that repairs data integrity problems in your Windchill system.

Download the latest WinDU and WinRU patches

Running the Windchill Diagnostic Utility (WinDU) and the Windchill Repair Utility (WinRU) Checklist.

Smooth transitions depend on the engineering staff being able to do their jobs as fast or even faster than when Windchill was on-premises.  PTC has guidance about how to assess Creo performance with Windchill on Azure, which will give you a leading indicator and the ability to resolve any performance problems before they have a chance to affect productivity and adoption.

• Creo Benchmark

If you would like additional help, PTC offers PLM Health Check. PLM Health Checks are delivered in a structured way to gather information, analyze the data, and present recommendations using PTC experience, industry, and product best practices.

Sales or your CSM can help you get started with this service. Contact them before getting started.

Over the evolution of your Windchill, custom features may have been created to support end-user requests or stop-gap a feature that was needed. Evaluate the value of those customizations against the cost of maintaining them and the value of out-of-the-box features.

Additional capabilities are common through continuous PLM improvement. Over time the increased number of customizations becomes inevitable. A significant amount of customizations becomes a future problem, which increases the cost of ownership and, more importantly preventing you from a future upgrade to the next version of PLM software. Windchill PLM Decustomization Analysis & Planning help you to standardize their PLM environment and to reduce the future cost of ownership.

Your architecture plan should specify what systems you need, how they should be configured, and what size those systems need to be to run your PLM system.

Designing an infrastructure for the intended user base and performance characteristics will take more time initially but make adoption and expansion much easier later.

When defining your infrastructure plan, you should consider:

• Availability: If Windchill is currently on a different upgrade/maintenance schedule than the other applications on the server, be sure to acknowledge that. Document system availability and acceptable downtime for Windchill.
• Environments: How many environments do you currently have to support new feature additions, and you will also need those same environments supported in Azure. We recommend a minimum of four environments:
1. Development: Also referred to as “dev,” this is the space your developers can use to create new applications, features, or work on patches.
2. Quality Assurance/Test: This environment lives between dev and prod. Here, you’ll validate and test new versions, patches, and configurations. Your QA/test environment should be as close of an exact replica to your prod environment as possible.
3. Staging: This environment is an identical copy of the production environment used to test the deployment of the package to ensure a smooth go-live.
4. Production: This environment will host the live, tested applications your end users will interact with. It’s often referred to as “prod.”

Document your final decisions and share them across the project team for execution. This document should outline the components you need, dependencies for an efficient upgrade, how they relate to each other, and where they need to be located.