The production database came across cleanly. The file-server replica at the second site did not. Its registration lives outside the database, so the import never carried it. We had seen it in rehearsal, so on cutover night it took one step to re-key and re-mount.
That's what moving Windchill into a government cloud is like. The big pieces travel. A dozen small ones don't, and you only find them by rehearsing.
Talk to the architect who ran it
We move production Windchill from on-premises servers into the client's own Azure Government tenant. We have done it for a clustered production system at an aerospace and defense manufacturer, the same environment behind our zero-outage upgrade case study.
You make defense or aerospace products. Your Windchill runs on servers you own, and the compliance program now says controlled technical data belongs in a government cloud. For most defense suppliers working toward CMMC, that means Azure Government, usually paired with a government Microsoft 365 tenant. You want to keep running the Windchill you have, with your customizations and integrations. Moving to a SaaS product is a different project.
We don't host Windchill, and we don't resell cloud capacity. The environment lives in your tenant, under your accounts and your security controls. We design it, build it, move the data and stay through cutover. If you'd rather have PTC run the whole stack, look at Windchill+ and check its current authorization status against your contracts.
Our client was on Windchill 12 and needed 13.1. The temptation is to do both in one weekend. We didn't. Production went to Azure Government unchanged, then got upgraded in place a few weeks later. Each change had its own rehearsals, its own go/no-go and its own rollback. (The client even put them on separate approval tickets. The cloud move was one of the biggest spends of their year, and it deserved its own approver.) It costs you a second weekend. In exchange, when something breaks, you know which change broke it.
The application servers in Azure were installed, rehosted and tested weeks before cutover. On the weekend itself, the work was data: import the database, sync the vault content, rewrite the host references stored inside the database, repoint the vaults, reconcile the users, rebuild the search index. Every slow, reversible step happened during the week with production still online.
The old production servers were not touched. If the go/no-go had failed, the plan was to power them back on at the old address. We also snapshotted every cloud server's disk before starting. That's two ways back, and neither depends on anything going right that night.
The cutover runbook was written from rehearsals, not from the vendor guide. It runs in execution order, each step has a check, and the person on the keyboard follows it line by line.
This is the list that turns a clean weekend into a long one. Each item came up in our rehearsals.
| What | Why it bites | What we do |
|---|---|---|
| Host names stored inside the database | Windchill records its own site address, vault hosts and mount paths in database tables. Import the database and it still points at the old servers. | Run PTC's rehost utility against the database and vaults, dry run first, then read back every table it changed. |
| File-server replicas | Replica registration and its keys live outside the database. | Re-key each replica to the new master and re-mount it, then test a download from each site. |
| A node added after the rehost | Our second cluster node joined after the rehost step, so its vault mounts kept the old Windows drive paths. | Check every node's mounts after cluster join, not only the first. |
| The directory | Moving to a cloud directory changes the user directory's identity. Windchill keeps a record of where each user came from. | Reconcile the directory records in one transaction, then confirm no user still points at the old directory. |
| Login names | Our client moved to email-address logins at the same time. | Back up the old names, check for duplicate email addresses first (there must be none), convert, and test a login per user type. |
| The search index | The index built on-prem points at the old system. | Delete it and rebuild from scratch, then watch the queue until every object is indexed. |
| Integration file drops | ERP interface folders lived on a local disk. | Move them to cloud blob storage, and put the middleware behind an API gateway. |
None of this is exotic. It's just not in one place in the vendor documentation, and missing any one of them shows up as a user calling on Monday morning.
Our client's IT team knew Windows far better than Red Hat, and the design called for Red Hat. That's an argument to have early, with the people who will patch the servers at 2 a.m. in the room. We moved to Red Hat. Windows would have worked too.
Azure Government bills data leaving the cloud. Every replica you feed costs money each time someone opens a big assembly. We started with two or three sites on the WAN and added replicas only where large-assembly latency was proven painful.
Our client chose manual rebuild-and-restore over automated failover, with their existing backup product as the system of record. The one hard rule: the application, the vault and the database are snapshotted together. A database restored to 2:00 and a vault restored to 1:00 is data loss, discovered later.
Start with the Microsoft monitoring the IT team already runs. You give up some visibility inside the Java process. You gain monitoring that someone actually watches on day one.
Put new reports on Windchill's REST and OData interfaces, not on direct database queries. Direct access skips Windchill's access control. For ITAR data, that is the access control.
A government cloud is more expensive to run than the server room you're leaving, and egress charges are easy to underestimate. You also take on things the hosting provider won't do for you: patching, backups, the operating system. Plan for two cutover weekends if you're also upgrading, and for the integration team to retest every interface against the new addresses. What you get is Windchill you still control, in an environment your compliance program can sign off.
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.
Cloud and upgrade work at Element is led by Erik Hetényi, solution architect, who ran both the government-cloud cutover and the Windchill 12 to 13.1 upgrade that followed it. We design the environment, write and rehearse the cutover, move the data and stay through go-live, working alongside your IT and security teams.
No. We build and run the migration into your own Azure Government tenant, and the environment stays yours. If you want a vendor-run service, ask PTC about Windchill+.
No, and we advise against doing both at once. Move the version you have, prove it, then upgrade in place. Our client moved Windchill 12 into Azure Government, then upgraded to 13.1 there: 40 of 40 upgrade phases, zero failures, zero production outage. (Read the case study)
For our client, one planned weekend window. The outage holds only the steps that need it: the final database and vault sync, the rehost, user reconciliation and the index rebuild. Everything else happens beforehand with production online.
They move with the system, unchanged, because the lift doesn't change the version. Retest every integration anyway, because it now talks to new hosts. We review customizations during the later upgrade, which is when old custom code tends to break.
No. The cloud gives you a compliant place to put the data. Windchill's own access rules decide who can see what, and we design both. (ITAR compliance in PLM)
Related knowledge
Tell us what you run today and where it has to land. We'll map the move, name what the import will leave behind, and plan the rehearsals.
Get Started
