Most Windchill still runs on-premise
Export control, an ERP next door, a datacentre that was paid for last year: there are good reasons not to move Windchill to the cloud, and we do not treat them as problems to be argued away. CI/CD is not a cloud feature. The discipline behind it, that every change is built from source, tested on an environment that matches production, and reversible by a job that has actually run, applies exactly the same in your own datacentre as in the cloud.
What differs is the last step. So we build the pipeline once and give it two ways to land.
One build, two delivery paths
Every change follows the same path, whether it is a PTC release, a CPS, or one of your customizations:
- Build. Customization packages are compiled from source with the Windchill build on every commit. The output is a versioned artefact, identical for both targets.
- Deploy to test. The artefact is installed on a test environment that mirrors production, by the same job that will later touch production.
- Verify. Automated smoke tests exercise search, check-in, change creation and the integrations you depend on.
- Promote. The tested artefact, not a rebuild, goes to production. Rollback is a job in the same pipeline.
On-premise
- Self-hosted agents inside your network. Source and artefacts never leave it. Use whichever source control you already have; the pipeline does not care.
- No outbound internet required. Dependencies come from an internal artefact repository and mirror, so a build is reproducible even when the firewall is closed.
- Automated deployment to your existing servers. Artefacts are staged, property changes and load files applied repeatably, and method servers restarted in rotation behind the web server so users are not dropped mid-session.
- Honest maintenance windows. Where a release genuinely needs a full stop, you get a scripted runbook rehearsed against a clone and timed, instead of an estimate.
- Rollback that exists. The deploy job takes a codebase snapshot and a database restore point before it changes anything, and the restore path is tested on every release to test.
- Air-gapped sites. Signed artefact bundles move through your controlled transfer process and are verified on the way in.
Cloud
- Containerised releases for method servers, background servers and search, built by the same pipeline.
- A managed cloud platform, with shared storage for vaults, a managed database and a secrets store, all described as infrastructure as code in your repository.
- Rolling method-server updates and traffic switching for zero-downtime releases where the Windchill version allows it.
- Environment cloning so test and training can be refreshed from production in hours rather than over a weekend.
Hybrid is the normal case
Most estates we work with are not purely one or the other. Source control and the build run in the cloud while self-hosted agents deploy into the datacentre. Test and training environments sit in the cloud while production stays on-premise. During a migration both targets are live at once, which is precisely when having a single pipeline stops being a nicety.
Building the pipeline first is also the cheapest way to prepare a move. Once releases are automated and rehearsed, changing where they land is a configuration change rather than a project.
Observability, either way
Dashboards and alerts for method servers, queues, vault storage and database health, wired to whatever monitoring you already use, in the cloud or on-premise. Backups and their restores are tested on a schedule, not assumed.
Where it runs and who owns it
Your subscription or your datacentre, your accounts, your data. We build and operate the environment; you own it and can take it over at any time. Handover is part of the work, not a separate phase: runbooks, infrastructure as code and a walkthrough with the people who will be on call.