Windchill upgrades that make cutover weekend boring

We upgrade production Windchill, including two-hop paths like 12 to 13.1 and moves to Windchill+, by rehearsing the whole upgrade until there is nothing left to find.

On our most recent production upgrade, all 40 of 40 migration phases ran with zero failures and zero production outage.

Talk to a consultant

A grey fighter jet in flight with its landing gear down against a cloudy sky

Who this is for

You run Windchill in production and you're one or more releases behind. Maybe support for your version is ending, maybe you need a feature in the new release, maybe a move to Windchill+ is on the table.

Most teams put upgrades off because the last one hurt: a weekend that ran into Monday, an integration that broke quietly, a customization nobody remembered. The risk doesn't live in PTC's upgrade guide. It lives in the gap between that guide and how your system has grown over the years.

We close that gap before cutover. See how it went on a clustered, government-cloud production system in the AI-verified upgrade case study.

How we run an upgrade

01
Inventory before anything moves.
Customizations, integrations to ERP and CAD, the cluster layout, vaults and replicas, the operating system underneath. Each one is a place where your production system differs from the vendor guide, and each gets a decision before the first rehearsal.
02
Rehearse until the surprises run out.
Copy production to a test system, run the whole upgrade, fix what broke, wipe it and run it again. Every rehearsal is designed to fail somewhere new; we stop when two runs in a row finish clean. The cutover runbook is written from those runs, not from the guide.
How the rehearsals work
03
Stage everything ahead, with production online.
Backups, the new release, every fix found in rehearsal: all in place the week before. The outage window holds only the steps that need one.
04
Human-led, AI-verified.
Scripted steps run through a governed AI assistant held to one rule: verify, never assert. It reports a step done only when it has seen the evidence (the log line, the row count). A senior architect owns every irreversible decision.
Verify, never assert
05
Keep a tested way back.
A written go/no-go point and a rollback that was rehearsed like everything else, so the question at hour thirty of a weekend already has an answer.

Where upgrades actually break

None of these are in the vendor guide, because they're specific to your environment. Each one came up in our rehearsals.

What	Why it bites	What we do
Cluster cache configuration	Settings that differ between nodes can crash-loop a node after the upgrade.	Found and fixed in rehearsal, so the production node comes up first time.
Vault mounts and replicas	File vaults, their mount strategy and remote replicas sit outside the database.	Check every node and replica after the move, and test a download from each site.
The operating system underneath	A major OS version change under a live application is its own project.	Rehearse it with the upgrade, on the same servers, in the same order.
Old customizations	Custom code written for the old release doesn't always survive the new one.	Inventory early; rework, retire or retest each one before cutover.
Configuration drift	Years of small changes nobody wrote down.	Repeated rehearsals surface it; we fix it before production instead of during it.

The tradeoff, stated plainly

This approach front-loads the work. The automation, the rules and the error catalogue are built before the first rehearsal, which a conventional plan doesn't need. You pay for that in the weeks before cutover and get it back on the weekend, and again on the next upgrade, which starts from a tested runbook instead of a blank page.

Where Element fits

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 of about sixteen, 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.

Upgrade work at Element is led by Erik Hetényi, solution architect, who ran the Windchill 12 to 13.1 production upgrade in the case study. We inventory the system, build and run the rehearsals, write the runbook and stay through cutover, working alongside your IT team.

A Production Windchill Upgrade: 40 Phases, Zero Failures, Zero Outage

40 of 40 migration phases, zero failures, zero production outage.

Read customer story

FAQ

How much downtime does a Windchill upgrade need?

One planned window, usually a weekend, sized from rehearsals rather than estimated. Everything slow and reversible (backups, staging the new release, applying fixes found in rehearsal) happens the week before, with production online, so the outage holds only the steps that need it.

Can we go straight from Windchill 12 to 13?

Not in one step. 12 to 13.1 needs two migration hops through the upgrade manager. We plan and rehearse both hops end to end as one upgrade, not as two projects.

How many rehearsals do you run?

As many as it takes for two runs in a row to finish clean. The industry habit is one or two because each rehearsal takes days of manual work; we automate most of the steps, so running more costs far less. (Why we rehearse more)

What happens to our customizations?

We inventory them first and decide, one by one, whether each survives the new release, needs rework, or should be retired. Old custom code is the most common reason an upgrade weekend runs long.

Should we upgrade or move to Windchill+?

It depends on how much you've customized, your hosting and compliance rules, and who you want running the servers. We do both and will tell you which fits. (What is Windchill+?)

What do we get besides the upgraded system?

A tested runbook, the rollback plan, a record of every problem found and fixed in rehearsal, and the list of configuration drift we cleaned up. That record makes the next upgrade cheaper.