Migrating from Arena PLM to PTC Windchill: A Practical Guide

Eric HornManaging PartnerMost companies that leave Arena for Windchill aren’t unhappy with Arena. It did its job while the business was one site, one product family and one quality system. What changes is the company around it. We’ve planned and run this move, Arena plus a SolidWorks PDM vault onto Windchill, and this guide is what we’d hand the next team before the first planning meeting: what moves, in what order, what the loaders can and can’t carry, and where these projects lose time.
If you’re still deciding between the two systems, start with our Windchill vs Arena comparison. This page assumes the decision is made.
Key facts
| What it really is | Two migrations: Arena holds the metadata (items, BOMs, changes, suppliers), and the CAD usually lives in a separate vault such as SolidWorks PDM. Reconciling the two is the hard part. |
| Tools needed | Windchill’s license-included loaders: LoadFromFile for parts, BOMs, documents, changes and suppliers; IXB packages for CAD documents; the type definition exporter for types and enumerations. |
| What can’t be loaded | Lifecycle history, approval signatures and running workflows. Security labels have to be configured by hand. |
| History fidelity | Parts keep their original creator and dates. Documents need a custom handler. CAD documents take the import date unless you carry the legacy values as attributes. |
| Load order | Types, users, containers, parts, documents, CAD, build rules, BOMs, links, changes, suppliers and AML, then history. |
| Biggest schedule risk | Matching CAD files to items and drawings, and data cleanup nobody budgeted for. The data work runs longer than the configuration. |
| Stopping rule for rehearsals | A full load on a test environment that verifies clean, object by object, with no manual fixes. |
| What stays behind | Obsolete and blank-status CAD, superseded CAD versions (the released PDF carries them), retired change workflows, and the Arena audit trail, which goes to an archive. |
Why growing companies outgrow Arena
In our experience the trigger is almost never a missing feature. It’s one of these, and usually two at once:
- Consolidation. Acquisitions leave several business units on different PLM systems. The company picks one standard, and Windchill is the one that already runs the larger units.
- Controlled data. Defense work brings ITAR and CMMC, and often a requirement to keep controlled data in a government cloud, next to the company’s standard Windchill.
- Mechanical depth. Arena’s strength is electronics BOMs and supplier collaboration. Complex mechanical assemblies, CAD-driven structures and a manufacturing BOM with process plans (MPMLink) are where Windchill is deeper.
- Multiple sites and a single change process. Once engineering and manufacturing sit in different places, the change process has to be one process with one record, and the ERP has to get the BOM from one system.
The tradeoff is real. Windchill takes longer to implement, needs more training and costs more to run. If none of the four triggers above apply to you, staying on Arena is a perfectly good answer.
Step 1: Inventory both sources before you design anything
Arena is the system of record for items, revisions, BOMs, change orders, quality records, suppliers and the approved manufacturer list (AML). It’s cloud-only, so extraction goes through Arena’s export and API. File attachments usually need a separate download path from the metadata; plan for it on day one.
The CAD vault is the second source. SolidWorks PDM keeps its metadata in a SQL database you can script against: documents and versions, assembly references, custom properties, workflow states and folders. One detail catches people out. PDM stores files on disk by internal document ID in a numbered folder tree, so a script has to resolve which archive file is which version of which drawing.
Before anyone maps a field, answer these per source:
- Do you need full revision history, or the latest released revision plus a record of the rest?
- Which change types are still in use, and which are retired?
- Are the Arena item numbers stored anywhere in the CAD files’ properties? (This decides how much matching is automatic.)
- Do the BOMs carry reference designators or effectivity?
- Which quality records (CAPAs, nonconformances) need to stay live, and which are history?
Write the answers down. Every estimate after this depends on them.
Step 2: Design the target, then map to it
Load into the Windchill you want, not a copy of Arena. That means the types, attributes, lifecycles and numbering are designed first, as part of the implementation, and the migration maps onto them.
Four decisions come up on every Arena migration:
- Part numbering. Arena sites often carry intelligent part numbers. We keep the legacy number as a searchable attribute on the migrated part, and new parts follow the new scheme.
- Revision schemes. Decide per type whether legacy parts keep revising on their old pattern or switch to the new one. If you don’t configure this before the load, the first revision after go-live jumps to the new scheme and nobody can explain why.
- Change types. For each Arena change type, choose carry forward (it gets a Windchill workflow) or history only (the records come across, with no workflow behind them). Retired types are history only.
- Quality records. Windchill’s loaders cover change requests, change notices and problem reports. Its own quality-module objects (CAPA action plans, nonconformances) have no loader. So decide where each legacy quality record lands: as a problem report or change request in Windchill, in a separate quality system, or in the archive.
Build a staging database between the sources and Windchill. It holds the extracted data, the mapping tables (users, lifecycle states, types) and a match table for items to CAD. It also tracks the load status of every object: pending, loaded, failed, verified.
Step 3: Load in the right order
What moves, and in what order:
- Type definitions and enumerations. Everything else references them.
- Users. Every source user who will appear as a creator has to exist in the directory first.
- Products, libraries and folders.
- Parts (items), latest released revision first, with creator, dates, attributes and lifecycle state.
- Documents and their files.
- CAD documents from the vault, through IXB packages.
- Build rules that link each CAD document to its part.
- BOMs. All parent and child parts must already exist. Use the occurrence form of the BOM load if you have reference designators; a spreadsheet import drops them.
- Part-to-document links.
- Change objects: change requests, change notices, change activities and their affected items.
- Suppliers, manufacturer parts and the AML.
- Earlier revisions, if you’re migrating history, in strict chronological order.
That last step needs a decision during the prototype. Loading old revisions after the BOMs can point a BOM at the wrong iteration, so some datasets have to be interleaved: revision A and its BOM, then revision B and its BOM.
What the license-included loaders can and can’t carry
Two Windchill tools do almost all of the work, and both come with the base license. LoadFromFile reads CSV or XML load files. IXB imports XML packages. PTC also has Windchill Bulk Migrator, available only through PTC services or select partners. Its main advantage is extractors that already know the Windchill data model, which doesn’t help when the source is Arena. Its staging and validation steps are easy to build yourself.
| Arena / PDM object | Windchill target | Loader | What survives |
|---|---|---|---|
| Item | Part | LoadFromFile | Number, name, attributes, revision, lifecycle state, original creator, original dates |
| BOM line | Part usage link | LoadFromFile | Quantity, unit, find and line number; reference designators with the occurrence form |
| Document and file | Document | LoadFromFile | Metadata and content. Original dates need a custom handler |
| CAD file (SolidWorks part, assembly, drawing) | CAD document | IXB only | Content, structure, part link. Dates and author become the import’s unless carried as attributes |
| Change order | Change notice, change activities, affected items | LoadFromFile | The record and its links. No approval trail |
| Change request, problem report | Change request, problem report | LoadFromFile | The record and its links |
| Manufacturer part, AML entry, supplier | Manufacturer part, AML entry, supplier | LoadFromFile | Full |
| Approval history, signatures, open workflows | none | no loader | Archive only |
History fidelity, in plain terms. A part can be created with the original creator and original created and modified dates, because the part loader accepts both. The creator and the last modifier come out as the same person on that first load. The standard document loader accepts no dates at all, so preserving document dates means a small custom handler, written and tested on a development system first.
CAD is where most teams are surprised. IXB ignores historical dates in a normal import, and there’s no supported setting that keeps both the original dates and the original authors. What we recommend: add two attributes to the CAD document type, legacy created-on and legacy created-by, and load the real values into them. They show on the info page, in tables and in search. The system columns still say migration day, and you should tell your quality team that before an auditor finds it.
Whatever you decide, decide it before the first production load. Windchill sets those dates when an object is first stored, and there’s no supported way to re-stamp an object after the fact.
Lifecycle state without the workflow. Objects can be loaded straight into Released or In Work without running a workflow. That’s what you want for a migration. It also means the lifecycle history behind that state, who promoted it and when, isn’t created. The Arena record of it goes to the archive.
Matching CAD files to their drawings and PDFs
This is the step that decides your schedule. Arena knows the item and usually holds a released PDF of the drawing. SolidWorks PDM holds the native part, assembly and drawing files. Nothing guarantees the two agree.
How we approach it:
- Match by number first. Where the CAD file name or a custom property carries the Arena item number, the match is automatic. Windchill doesn’t need the CAD file name to equal the part number; the build rule makes the link.
- Then by property, then by hand. Record how every pair was matched (number, property or manual) in the staging match table.
- Compare against the released PDF. The PDF in Arena is the record of what was released. A native file that doesn’t correspond to it is a finding, not a load error.
- Flag what’s left. Unmatched files that still matter are migrated with a flag on the part, so engineers know the pair was never validated. Nobody has to pretend it was.
- Leave the rest behind. Obsolete and blank-status files stay in the vault archive.
Only the latest CAD version moves. The released PDFs carry the earlier revisions, and they’re far easier to read in an audit than a stack of superseded native files.
Two technical traps on the CAD side. First, capture the CAD application and document type values from a real Workgroup Manager check-in on a development system, then build your IXB packages from those values; guessed values produce CAD documents Windchill doesn’t recognize. Second, keep each IXB package to one iteration per CAD document. A package carrying several iterations of the same file fails and rolls back the whole batch, innocent files included.
Expect thumbnails and viewables to lag after a large CAD load. Publishing works through the queue for days, so don’t book the executive demo for the Monday after cutover.
Rehearse the load, then verify the loaded object
A loader that exits cleanly hasn’t proved anything. We’ve seen loads report success while rows were skipped, fields were defaulted, a type was created twice because a load file left its namespace blank, or a workflow load wrote nothing at all. A CSV row whose last column is empty can be dropped without a message.
So the rule on our projects is to verify the loaded object, not the loader’s success. After each load:
- Count: parts, BOM lines, CAD documents and build rules in Windchill against the source and the match table.
- Sample: open objects in the running application and read back the fields that matter: creator, dates, state, attributes, revision.
- Structure: compare BOM depth and a sample of full assemblies, source against target.
- Read the server log for the load window, including warnings. A warning in a migration is a question until someone answers it.
Then rehearse. Start small on a development system (a handful of parts, a few assemblies with content, one hand-built CAD document, one build rule) and prove each mechanism. Then run the full dataset on a separate test environment, verify it, fix the transforms, and run it again. Stop when a complete run verifies clean with no manual fixes. That run is your production procedure, timed.
This is the same discipline we use on upgrades. (Why we ran eight rehearsals instead of two, and the verify-never-assert rule behind it.)
Cutover
The rehearsals tell you how long the production load takes. Build the cutover around that number:
- Freeze Arena. Set a date after which no new changes start in Arena. Changes already in flight either finish in Arena before the freeze or close there and restart in Windchill. Don’t try to migrate a half-approved change.
- Take the final extract from Arena and the CAD vault, after the freeze.
- Run the rehearsed load into production, in the rehearsed order, with the same verification.
- Business sign-off. Engineering, quality and manufacturing each check a sample they chose themselves, not one the migration team picked.
- Go live, with Arena read-only for a defined period, so people can check what they remember against what moved.
If the company is consolidating several business units, migrate them one at a time. Each unit moves as it is into its own organization, and the units converge on shared types and processes afterward. Harmonizing everything up front sounds tidier, and in our experience it stalls on decisions nobody owns.
What stays behind
Decide this in writing, early, and get quality to sign it:
- The Arena audit trail. Approvals, signatures and workflow history can’t be loaded. Export them to a read-only archive and link to it from the migrated objects.
- Retired change types and their workflows. The records come across as history; the workflows don’t.
- Superseded CAD versions. The released PDF of each revision is the history.
- Obsolete and blank-status CAD files.
- Open workflow tasks. Finished before the freeze or restarted in Windchill.
Arena is a subscription. When it ends, so does your access to anything you didn’t export, so the archive has to exist before the contract runs out.
Common traps
- Treating it as one migration. The CAD vault is its own project with its own schedule.
- Assuming a clean exit means a clean load. Verify the objects.
- Deciding history after the first load. Dates are set when an object is first stored.
- Copying Arena’s data model. Design the Windchill target, then map.
- Forgetting security labels. They have no loader. In an ITAR environment, configure and test them before any controlled data is loaded. (ITAR compliance in Windchill.)
- Leaving revision schemes for later. The first revision after go-live will tell you, loudly.
- Booking the go-live demo too early. Viewables take days to catch up.
- Underestimating cleanup. Duplicate part numbers, orphaned CAD references and BOMs that point at retired parts all surface in the first full rehearsal. Budget time to fix them at the source.
Who does this work
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, 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.
We’re running an Arena and SolidWorks PDM consolidation onto Windchill now, and the method on this page is the one we use. A platform migration comes with an implementation attached, and that side follows our process-first Windchill implementation. The tradeoff with hiring us: we’re small. We won’t staff a large global program, and we’ll say so on the first call.
FAQ
Can you migrate from Arena PLM to Windchill without buying a migration tool?
Yes. Windchill’s license-included loaders cover what an Arena migration needs: LoadFromFile creates parts, BOMs, documents, change requests and notices, manufacturer parts, the approved manufacturer list and suppliers, and IXB import packages create the CAD documents and their links. PTC’s Windchill Bulk Migrator is only available through PTC services or select partners, and its main advantage, extractors that already know the Windchill data model, doesn’t apply when the source is Arena.
Does Arena change history carry over to Windchill?
The records do; the audit trail behind them does not. Change requests, change notices and their affected items load into Windchill, and objects can be loaded directly at their released state. Lifecycle history, signatures and running workflow instances have no loader, so the approval trail stays in an archive of the Arena data, linked from the migrated objects. Decide per change type whether it gets a live Windchill workflow or comes across as history only.
How do you migrate SolidWorks PDM files alongside Arena data?
Treat it as a second source. Extract the vault metadata and the files, match each CAD file to its Arena item and released PDF, and load the CAD as Windchill CAD documents through IXB packages, one iteration per package. Files that don’t match automatically are curated by hand or migrated with a flag on the part, so engineers know the pair was never validated. Obsolete and blank-status files stay behind.
Do original created dates and authors survive an Arena to Windchill migration?
Partly. Parts can be loaded with their original creator and created and modified dates. The standard document loader has no date support, so documents need a small custom handler. CAD documents imported through IXB take the import date and account; the practical answer is to carry the legacy date and author as searchable attributes. Plan all of this before the first load, because Windchill has no supported way to re-stamp an object after it is stored.
Who can migrate us from Arena PLM to Windchill?
Element Consulting, an independent PTC partner, is moving an aerospace and defense supplier from Arena and SolidWorks PDM onto Windchill now, using Windchill’s own loaders and a rehearsed, verified load. Element has run 100+ PLM implementations since 2003 with a senior-only team. Ask any firm you consider how it verifies what was loaded, beyond the loader’s success message.



