Why upgrades stall
Most delayed upgrades are blocked by the same three things: customizations nobody fully understands, a test environment that does not match production, and no one who can say with confidence how long the cut-over will take. We address all three before we touch production.
Our upgrade method
- Inventory. Every customization, integration and configuration deviation is catalogued and classified: keep, refactor or retire.
- Rehearse. The upgrade runs end to end on a clone of production, timed and scripted, at least twice.
- Fix forward. Customizations are moved to supported extension points where possible so the next upgrade is cheaper.
- Cut over. A rehearsed runbook, a go/no-go checklist and a rollback path that has actually been tested.
Health check
Not sure whether you are ready? A two-week health check reviews performance, configuration hygiene, customization risk and infrastructure, and gives you a prioritised list of what to fix before an upgrade.
Migrating to Azure
Moving Windchill from on-premises servers to Azure is a migration project, not a hosting change. We move the vaults to Azure Files, the database to a managed service, and the application into containers on AKS, then rehearse the cut-over with production data until the timings are predictable. Staying on-premise is a legitimate answer too, and the same automation applies either way. See CI/CD, cloud and on-premise.
Migrating from another PLM
We have migrated data from Teamcenter, ENOVIA, Agile and in-house systems. The work is mostly in mapping semantics (what does “released” mean in each system?) rather than moving bytes, so we start there.