How We Ran a Production Windchill 12→13.1 Upgrade With Zero Outage — Using AI the Way It Should Be Used

By Erik Hetenyi, Solution Architect & System Administrator,

Most teams dread Windchill upgrades. I understand why. A major-version jump on a live PLM system is one of those projects where "mostly worked" isn't a passing grade — a cluster that won't come back up on Monday morning is a very public failure.

So when we took a client's clustered Windchill stack from 12.0.2 to 13.1.3 — in a regulated, government-cloud environment, with an operating-system major-version leap underneath a live application — the goal wasn't heroics. It was the opposite: make the scary parts boring.

Here's how it went, and what we actually did.

The result first

There's no direct upgrade path from Windchill 12 to 13.1 — it takes two sequential migration hops. Add the OS leap, a file-vault relocation, a ~98,000-object reindex, and a remote file-server replica to rebuild, all inside one weekend window with a hard Monday point-of-no-return, and you have a project with a lot of ways to go wrong.

None of them did. That wasn't luck.

Where a Windchill 12→13 upgrade actually breaks

The real risk doesn't live in PTC's happy-path guide. It lives in the gap between that guide and your production environment:

• the cluster cache configuration between nodes,

• the vault's mount strategy,

• the replica's authentication,

• the OS leap under a live app.

Any one of those seams can turn a clean upgrade into a 2 a.m. cluster that won't come back up. The guide doesn't cover them because they're specific to how your environment grew over the years — and that's exactly the stuff that bites you at cutover.

Our method: human-led, AI-verified

We didn't bet on a single flawless attempt. We bet on rehearsal and verification — and we used a carefully governed AI assistant to multiply one architect's reach without ever letting it drive off a cliff.

1. Rehearse until it's boring

The visible event was a weekend. The actual work was three months. We ran eight full rehearsals across three environments before issuing a single production command. Each rehearsal was designed to fail somewhere new, and every failure got captured as a catalogued, permanently-fixed gotcha. By cutover night, the production binaries already carried every fix from all eight runs.

2. Stage everything ahead, online

All the slow, reversible work — backups, pre-staging the target binaries, promoting every rehearsal fix — happened during the week before go-live, with production fully online. The outage window ended up containing nothing but the steps that genuinely require one.

3. A governed AI assistant, held to strict rules

We ran the scriptable work through an agentic AI assistant (Claude, via Claude Code) under a hard set of standing principles:

• Verify, never assert. It could not claim anything was done or working unless it observed the evidence in that same step — the actual log line, the row count, the status code. "The script reported success" is not verification.

• Stop at the irreversible edge. Anything touching database schema, migrations, or vault location required explicit human sign-off. The line was drawn at reversibility, not difficulty.

• The human owns every GUI checkpoint and every irreversible decision. The AI executed and verified everything scriptable; I drove the interactive migration steps and every "are you sure."

• Say "I don't know" instead of guessing. Every time it hit something undocumented, it stopped and surfaced the evidence rather than improvising on production.

The single most valuable thing we produced wasn't a runbook. It was a consolidated, idempotent, adversarially-reviewed staging checklist: a ~100-item inventory deduplicated to ~30 canonical "verify → apply" fixes, then run through a "what's missing, what's unverified, what do the docs disagree on" critique before production was ever touched.

The cutover was a non-event — on purpose

The payoff of eight rehearsals is that the dangerous moments weren't dangerous anymore. The cluster cache-configuration issue that would have crash-looped a node at 2 a.m.? Found, understood, and fixed weeks earlier in rehearsal — so it worked on the first attempt in production. The OS leap landed first try. Both migration hops ran their full phases with zero failures. The irreversible vault cutover took two minutes, fully logged, with a rollback backup in hand.

I'll be honest about the division of labor, because it's the whole point: the AI kept me out of a hundred small errors and watched the tedious things a human skips at hour three — while my domain knowledge kept the AI from a dozen confident wrong turns and supplied the handful of facts no amount of log-reading could surface. Neither of us would have run it as cleanly alone. On a production system, "neither alone" is exactly the right amount of redundancy.

The real deliverable is the capability

The upgrade is the visible result. The repeatable capability is the one that matters: thirty catalogued gotchas, an idempotent staging checklist, a real-time execution log, and a validated rollback — institutional memory that turns the next upgrade from a gamble into a routine.

It proved itself immediately. After go-live, with the refresh procedures now battle-tested, the same AI assistant refreshed four lower environments in parallel, start to finish in under two hours, fully autonomously — each one verified and login-tested before it reported done. Work split by reversibility, not difficulty: human-led where the stakes were irreversible, fully autonomous where it was scripted and safe.

The takeaway

If a Windchill upgrade, cloud migration, or cluster modernization is on your horizon — especially in a regulated or government-cloud environment — it doesn't have to be the weekend everyone dreads. The fear comes out the way it's actually removed: through rehearsal, verification, and a disciplined human-in-the-loop AI method that catches problems at minute two instead of minute forty.

That's not AI hype. It's AI held to the same standard you'd hold a careful engineer to: show me the evidence.

Talk to Element about your upgrade →