The Windchill+ Migration Guide Nobody Writes

Windchill+ is on a lot of roadmaps right now. PTC's documentation will tell you how the conversion works — and it's good documentation. What it won't tell you is what actually decides whether the move succeeds, because none of it is about the software.

We've now taken manufacturers through this move, and the honest version of the guide looks nothing like a technical runbook. It looks like a series of uncomfortable decisions, made in the right order, before anyone touches a server.

The move is a purge, not a transfer

Here's the thing the brochure skips: a migration is a chance to fix what's broken — or to move it to the cloud intact.

Your current Windchill environment is probably carrying years of sediment. Customizations someone built in 2014 for a workflow that no longer exists. Part-numbering conventions maintained in Excel because "that's how we've always done it." A change process with official steps everyone routes around. Settings nobody remembers introducing, for reasons nobody remembers having.

Lift all of that into Windchill+ and you get the same problems with a better SLA.

So the first phase of a real migration isn't technical at all. It's an inventory with one question asked of every customization, every workflow, every convention: does this earn its keep, or is it a habit you've been paying to maintain? In our experience the honest answer for a large share of accumulated customization is habit — and every piece you leave behind is one less thing to migrate, one less thing to test, and one less thing PTC's future releases can break.

This is also the moment to be honest about a constraint of SaaS that on-prem never enforced: Windchill+ limits how much you can customize — deliberately. That's not a bug in the plan; for most teams it's the treatment. But it means the purge isn't optional. Anything deeply custom either gets rebuilt as configuration, replaced by process, or consciously retired. Deciding that list after you've committed to a cutover date is how migrations go sideways.

Your environment is lying to you

Long-lived systems accumulate drift. When we ran a recent production Windchill upgrade — 40 phases, zero outage — the rehearsals kept surfacing problems that had nothing to do with the upgrade: configurations left over from versions two generations back, settings that contradicted each other, fixes for problems that no longer existed.

The system worked anyway, the way a house with quirky wiring works — until you renovate.

A move to Windchill+ is the renovation. Every piece of drift in your environment is a place where the migration behaves differently than the documentation says it should, because the documentation assumes an environment that matches the spec — and after ten or fifteen years, yours doesn't. Budget for an audit you didn't schedule. It will pay for itself the first time a rehearsal fails somewhere the runbook said it couldn't.

Rehearse until the cutover is boring

The industry norm for migration rehearsal is one dry run, maybe two, because manual rehearsal is expensive. The norm is also why cutover weekends are dreaded.

Our position: rehearse until nothing new breaks — then once more. On that recent upgrade we ran eight full rehearsals. Every single one failed somewhere new. Not the same failure repeating — a new failure, each time, surfaced by drift and edge cases no plan could have predicted. The production cutover then executed all forty phases cleanly, and the strangest thing about the weekend was that nobody was nervous.

That's the standard worth holding a Windchill+ migration to: the cutover should be a non-event. If the team is bracing for the weekend, the rehearsal count was wrong. (With automation, the cost argument against rehearsing collapses — repeated runs get cheaper, not more painful. That changes the economics of the whole approach.)

The data question is really a data-honesty question

"Migrate the data" sounds like one line item. It's actually a decision about every object in the system: does the history come, or a baseline? Do obsolete parts come? Do fifteen years of ECNs come, or the open ones plus a read-only archive?

Bring everything and you've paid to move your mess. Bring too little and engineering loses the history it quietly relies on. There's no universal answer — but there is a universal mistake, which is not asking the question until the migration tooling forces it, at which point the answer is whatever's fastest.

The people side decides the outcome — again

The same finding as every PLM effort: the software is the easy part.

A Windchill+ move changes how people work even when the screens look similar — customizations they leaned on are gone, processes that routed around the system now go through it, and IT's role shifts from running servers to managing a vendor relationship. That last one is its own change-management case: somebody's job just changed shape, and pretending otherwise is how you get quiet resistance from the people you most need on side.

If you've read our take on who should own change management, you know the failure mode: the people side gets assigned to the team doing the technical migration, where it loses to hard deadlines every week. On a Windchill+ move, give it a named owner who isn't on the cutover's critical path.

What the sequence looks like

1. The purge decision. Inventory every customization and convention. Keep / rebuild-as-config / retire. This is a workshop with the people who use the system, not an IT spreadsheet exercise.

2. The drift audit. Find out what your environment actually is, as opposed to what the documentation says it is.

3. Process design. The workflows you'll run in Windchill+ — designed before migration, not discovered after.

4. Data scoping. What comes, what archives, what dies. Decided on purpose.

5. Rehearsed migration. Automated where possible, repeated until boring.

6. Change management, running the whole time — champions, communication, training, with its own owner.

7. A cutover that's a non-event. That's the deliverable.

The uncomfortable question to ask any migration partner

"What did the last one break, and how many rehearsals did you run?"

If the answer is "nothing" and "one," they either got lucky or they weren't looking. Ask us and you'll get a list — which is exactly why our cutovers are boring.

Windchill+ on your roadmap — even at the "we should probably look at this" stage? The earlier the purge conversation happens, the cheaper it is. [Talk to Element] — or read what Windchill+ actually is first.