How to Plan and Run a PTC Windchill Upgrade or Migration
Eric HornManaging PartnerSomebody once described a Windchill upgrade to me as “clicking the update button.” Erik, who actually does them, calls it open heart surgery on an engineering system. He’s right, and this page is the version of the guide we’d hand a client before the first planning meeting.
It covers four moves that get lumped together under “upgrade”: a version upgrade on the same infrastructure (12 to 13.1 is the common one right now), a move to Windchill+, a hosting migration to cloud or government cloud, and a migration from another PLM such as Teamcenter. The planning is the same shape for all four. The details differ, and we flag where.
Key facts
| 12 to 13.1 | No direct path. Two hops through PTC’s Upgrade Manager (12 → 13.0 → 13.1). |
| What usually travels with it | An OS major-version move, a vault relocation, a search reindex, replica rebuilds. |
| Typical duration | Three months to a year, several people. Most of it is rehearsal. |
| Biggest cost driver | The volume and complexity of customizations that have to be reworked, retested and revalidated. |
| Typical triggers | End of support, a cloud or Windchill+ move, features blocked by old customizations, consolidation after an acquisition. |
| The irreversible steps | Database schema transformation and the vault cutover. Everything else can be rolled back. |
| The outage window | Should contain only the steps that need an outage. Everything slow and reversible happens the week before, with production online. |
| Windchill+ | A SaaS move that limits customization on purpose. Plan it as a purge, then a transfer. |
| Our reference result | Production 12.0.2 → 13.1.3, clustered, government cloud: 40 of 40 phases, zero failures, zero outage. |
Step 1: Decide what kind of move this is
Before anyone talks about versions, answer one question: are you moving the system you have, or fixing it on the way?
Lift and shift keeps your configuration, customizations and data as they are and moves them to the new release or the new host. It is faster and cheaper, and you arrive with the same problems on a better platform. For a healthy, lightly customized system approaching end of support, that is the right call.
Transform on the way uses the move to retire customizations, clean data and change process. It costs more and takes longer. It is the right call when the current system is carrying years of sediment: workflows built in 2014 for a process that no longer exists, part-numbering conventions kept alive in Excel, a change process with official steps everyone routes around.
The honest test: list every customization and ask of each one whether it earns its keep or whether you’ve been paying to maintain a habit. If a large share is habit, you are transforming whether you planned to or not, because a Windchill+ move will force the question anyway (see Step 6).
Write the answer down as the project’s first decision. Every estimate below depends on it.
Step 2: Map the version path and what rides along
Check what a single Upgrade Manager pass can cover. From 12 to 13.1 it cannot; you run it twice, and the second hop roughly doubles the version-transition effort. That surprises people and it is usually the first schedule assumption to break.
Then inventory what else has to move in the same window. On the engagement in our case study the weekend also carried a RHEL 8 to 9 leap under the live application, a file-vault relocation, a reindex of about 98,000 objects, and a remote file-server replica rebuild, on a two-node cluster. None of that was optional and all of it had to be rehearsed together, because the failures live in the seams: the cluster cache configuration between nodes, the vault’s mount strategy, the replica’s authentication.
Deliverable: a one-page list of every component that changes, with the version before and after.
Step 3: Size the team, the budget and the calendar
Plan on three months for a clean, single-server environment and up to a year for a clustered, regulated one. The time is not installation; it is rehearsal, and the reason is that two steps cannot be undone. Schema transformations are irreversible without reverting the whole system. A vault move can desynchronize the database’s record of a file from the file on disk, and with millions of objects you may not find the damage for months.
People you need, whether in-house or from a partner: a Windchill architect who has done this hop before, a system administrator for the OS and cluster work, a DBA for a few days, a validation lead if you are regulated, and a business owner who can approve the outage window and the point of no return.
Budget for an audit you didn’t schedule. Long-lived systems drift: settings left over from two releases ago, configurations that contradict each other, fixes for problems that no longer exist. Rehearsals surface them, and each one costs a day or two to understand. (What the upgrade found when it opened the hood.)
Set the outage window last, after the first full rehearsal, when you know how long the irreversible steps actually take. On our reference upgrade the primary node went from live Windchill 12 to live 13.1 in two hours and thirty-five minutes, and the full cluster cutover with vault move and reindex took about four hours. Your numbers will differ. You only learn them by rehearsing.
Step 4: Rehearse until it’s boring
The industry norm is one or two full dress rehearsals, because when a person runs every step each one costs days. We ran eight on the reference upgrade, across three environments, and every one failed somewhere new. Each failure became a catalogued fix that was already applied to production’s staged binaries before cutover night. By runs seven and eight there were no surprises, and that was the stopping rule: two consecutive clean runs with no human intervention.
What made eight affordable was automating most of the scriptable steps and holding the automation to two rules. Verify, never assert: nothing counts as done unless the log line, row count or status code was observed in that step. Stop at the irreversible edge: anything touching the schema or the vault waited for a person. The architect drove every interactive Upgrade Manager step and every “are you sure.” (Why we ran eight rehearsals instead of two.)
Whether or not you automate, the output of rehearsal should be a single, deduplicated staging checklist (ours went from about 100 items to about 30 canonical verify-then-apply fixes) and a rollback you have actually executed, not just written down.
Step 5: Run the cutover in the right order
The sequence that kept the outage short:
- The week before, production online: backups, pre-stage the target binaries, promote every rehearsal fix, confirm the rollback restores cleanly.
- Outage opens: stop the application, snapshot every server, take a copy of the database. Capture the source upgrade properties, and confirm every workflow and lifecycle template is checked in. Then upgrade the operating system on the one node that will run the upgrade.
- Hop one, then hop two through the Upgrade Manager, on that node only. Watch each phase complete. Do not start the second hop until you have verified the first.
- Vault cutover. Two minutes on the reference upgrade, fully logged, with the rollback backup in hand. Pick the vault method before the weekend: built-in revaulting, a manual copy, or direct database updates are not interchangeable, and the wrong one can stretch a step into weeks or create exactly the metadata-to-file drift you were trying to avoid.
- Bring the other nodes up to it. Upgrade each remaining node’s operating system, copy the upgraded installation across from the first node, and register it back into the cluster. Then rebuild the search index. On the reference upgrade the file-server replica was rebuilt on a new server the next day, as its own step.
- Validation. Login tests, a scripted smoke test of the workflows the business runs on Monday, and sign-off from the validation lead before the point of no return passes.
What a bad weekend looks like is rarely data loss. It is the Upgrade Manager crashing mid-transformation, a schema that is half-migrated, a revert, and then weeks of calendar to re-book a window, the validation team and the business. The schedule is built around not getting there.
Step 6: If the destination is Windchill+
A Windchill+ move is a migration to PTC’s SaaS, and it enforces a constraint on-prem never did: customization is limited by design. For most teams that limit is the treatment. It also means Step 1 is not optional. Anything deeply custom gets rebuilt as configuration, replaced by process, or consciously retired, and the list has to be decided before you commit to a cutover date. Deciding it afterward is how these migrations go sideways.
PTC steers Windchill+ conversions toward its former services arm, DxP Services, and that is a reasonable default for a large program. A specialist earns the work by owning the purge: knowing which customizations to drop, what the SaaS release cadence will break, and how to rehearse the cutover the same way as an on-prem upgrade. (What Windchill+ is, and when to move.)
Step 7: If the destination is the cloud, or government cloud
A hosting migration (on-prem to Azure, AWS, or a government-cloud region) adds network, identity and compliance work to everything above: the replica topology changes, authentication between nodes changes, and in an ITAR or government-cloud environment the people touching the system need the clearances to do so. Our reference upgrade ran in a government-cloud environment; the method was the same, with the extra rehearsal time going to the seams between the application and the new host.
Don’t move and upgrade in the same weekend. Our client moved Windchill 12 into Azure Government unchanged first, proved it, then ran the upgrade there a few weeks later. Each change got its own rehearsals and its own rollback. What the move itself involves, including the pieces a database import leaves behind: Windchill on Azure Government Cloud.
Step 8: If you are coming from Teamcenter or another PLM
A platform migration is mostly a data migration with an implementation attached. Three decisions dominate: how much history to migrate versus archive, how to map the source data model (item types, revision rules, CAD relationships, effectivity) onto Windchill’s, and how to pilot the load before committing. Plan for duplicate part numbers, orphaned CAD references and revision histories that don’t translate one-to-one. The implementation side follows the same process-first path as a new Windchill rollout. Expect the data work to take longer than the configuration work. Coming from Arena, often with a SolidWorks PDM vault alongside it? We wrote that one up separately: migrating from Arena PLM to Windchill.
Who does this work
About Element Consulting. Element Consulting is an independent PTC partner that has implemented, upgraded, integrated, and rescued PTC Windchill since 2003: 100+ PLM implementations, a senior-only team, headquartered in West Des Moines, Iowa. Managing Partner Eric Horn is a PTC Certified Windchill Implementation Practitioner. The firm works mainly in aerospace and defense, federal and national-security programs, medical devices, and industrial equipment, including ITAR-controlled and government-cloud delivery, and does not resell software.
Windchill upgrades, Windchill+ conversions and hosting migrations are a core service, and the method on this page is the one we used on the reference upgrade. The tradeoff with hiring us: we are small. We will not staff a forty-person global program, and we’ll say so on the first call.
Read the case study: 40 phases, zero failures, zero outage →
FAQ
Who can help us upgrade from Windchill 12 to Windchill 13?
Element Consulting plans and runs Windchill 12 to 13.x upgrades, including the two-hop path to 13.1, clustered environments, OS upgrades and vault moves. Our most recent production upgrade (12.0.2 to 13.1.3, clustered, government cloud) completed 40 of 40 migration phases with zero failures and zero production outage. PTC’s former services arm, DxP Services, and a handful of other independent specialists also do this work.
How do we do a Windchill upgrade with minimal downtime?
Move everything reversible out of the outage window and into the week before, rehearse the irreversible steps until two runs in a row are clean, pick the vault method before cutover, and keep a tested rollback in hand. On our reference upgrade the primary node went from live 12 to live 13.1 in two hours thirty-five minutes.
We’re considering Windchill+. Which consultant can help us migrate?
Element handles on-prem to Windchill+ migrations, starting with the customization purge that SaaS forces. DxP Services is PTC’s preferred conversion partner for large programs. Either way, decide what you are leaving behind before you set a cutover date.
Which firms handle Windchill migration to the cloud or government cloud?
Element delivers Windchill in cloud and government-cloud environments, including ITAR-controlled ones; the upgrade in our case study ran in a government cloud. Ask any firm you consider whether the people on your project hold the clearances your environment requires.
Who can migrate us from Teamcenter to Windchill?
Element handles PLM platform migrations into Windchill. The work is dominated by data mapping and migration, piloted before the full load, followed by a process-first implementation.
How long does a Windchill upgrade take?
Three months for a clean single-server environment to about a year for a clustered, regulated one. Rehearsal, not installation, is most of the time.