01 What exactly is a PLM data migration?
A PLM data migration consists of transferring the technical repository from one system to another: from Windchill to 3DEXPERIENCE, from a homegrown legacy to Teamcenter, or from several instances into one. But the honest definition is more demanding. It means rebuilding a product structure inside an object model that does not describe it the same way.
A PLM holds links as well as files: part references, bills of materials, CAD associations, maturity states and dependencies. Copying files without preserving these relationships leaves the product structure incomplete. Check the coverage of the migration tools against the actual source and target models.
Technical data without its structure is just noise. The entire migration is decided there.
02 PLM vs ERP: what actually changes
An ERP handles tabular records: parts, orders, postings. A PLM handles a graph of versioned objects: parts with their revisions and iterations, structures with their effectivities, CAD models with their file-to-file dependencies.
Three direct consequences. Load order matters: a bill of materials loaded before its parts fails. Volume is measured in links as much as in objects: ten thousand parts can carry hundreds of thousands of relationships. And CAD brings its own constraints: binary integrity, cross-file references, assemblies that must reopen in the target system.
Migrating a management system rather than a technical repository? The ERP side has rules of its own: see the ERP data migration guide.
03 Which data to migrate: structures, CAD, history
PLM scope is decided layer by layer, each with its own trade-off:
- The parts repository (WTParts, Physical Products): the backbone. Deduplicate and shape it to the target model first;
- Structures and bills of materials, with their effectivities and views: this is where the links live, and the surprises too;
- CAD documents and models, with their cross-file dependencies: a migrated assembly must reopen, not merely exist;
- Associated documents (specifications, drawings, definition files) and their attachments;
- Revision history: decide which revisions and evidence must remain accessible, then compare full migration with a reduced operational scope and an archive. The cost depends on dependencies, access and retention requirements.
04 Reconcile the source and target product models
Windchill and 3DEXPERIENCE organise parts, CAD documents, relationships and maturity states differently. Define and verify the source-to-target mapping against your configured models, attribute by attribute, state by state and relationship type by relationship type.
Documentation provides a starting point. Customisations, local lifecycles and team conventions require additional analysis with business owners. Our Windchill migration article describes the questions to examine.
05 The audit: measure the graph, not count the files
Counting objects is not enough: you have to measure the links, the revisions, the states, and above all the anomalies. Orphaned objects, bills of materials pointing to deleted parts, duplicate codifications: the data audit makes them visible before they derail the load.
Check for additional sources: other PLM instances, side CAD vaults and local reference files. The audit maps their ownership and dependencies so the agreed scope does not omit part of a product structure.
06 The five phases of a controlled migration
The approach is the same as for an ERP; what adapts to PLM is the content of each phase. Our full methodology details them; in short:
- 01 · Audit: measure objects, links, revisions and anomalies across all sources;
- 02 · Build: build a chain that respects dependency order and rebuilds the links;
- 03 · Run / Fix: execute by product and assembly families, correct, loop until stable;
- 04 · Dry Run: the dress rehearsal at real volume, CAD included;
- 05 · Go-Live: cutover after structural reconciliation, CAD acceptance checks and review of remaining exceptions.
07 The pitfalls specific to PLM
On top of the classic migration pitfalls come those of the graph:
- The migrated file is not the migrated data. A CAD model that arrives intact but cut off from its links is a part without a product;
- Custom lifecycle states. "Under site validation" has no standard equivalent in the target: every custom state requires a mapping decision;
- Parallel revisions and branches, which linear bridges cannot represent;
- Assemblies that no longer open: CAD cross-file references must be rewritten, not copied;
- Loading out of order. Dependencies impose strict sequencing. That is precisely what an asynchronous chain with queues and replay can orchestrate without freezing at the first discrepancy.
08 Big bang, phased, or trickle: choosing your approach
The same three cutover strategies exist as on the ERP side, but the graph changes which one is realistic. A PLM cannot always be split cleanly, because the split has to fall on a boundary the product structure recognises.
Comparing PLM cutover strategies | Strategy | Organisation | Main constraint | Evidence before cutover |
|---|
| Big bang | One window for the agreed repository scope | Freeze time and verification of assemblies | Timed full-volume rehearsal and structural reconciliation |
| Phased | Waves by coherent product family or site | Components shared across waves | Ownership and synchronisation rules for shared objects |
| Trickle | Incremental transfer during coexistence | Revisions and relationships changing in both systems | Change capture, conflict resolution and consistency of each assembled structure |
09 What determines the budget
The estimate must cover objects, relationship types, revisions, lifecycle states, CAD dependencies and source systems. Custom rules and business decisions can require more effort than the raw object count suggests.
A broken product structure can remain unnoticed until an engineer opens an affected assembly. Plan structural reconciliation and CAD acceptance checks before cutover rather than relying on the load report.
The readiness audit establishes the scope and analysis needed for a proposal. Public ERP programme costs discussed in our cost article are not a benchmark for pricing a PLM migration.
10 A real anonymised case: the assembly that would not open
A mechanical equipment manufacturer, moving from Windchill to 3DEXPERIENCE. Around 38,000 WTParts, 210,000 relationships, twenty years of history, and a native migration tool that had already been run once as a proof of concept. The proof of concept was declared successful.
What the audit found. The proof of concept had migrated 500 parts chosen for being simple. On the full extract, three findings changed the plan. First, 4,200 CAD documents held references to files that had been moved between vaults years earlier: the links resolved in Windchill through a legacy mapping table nobody had documented. Second, the lifecycle carried eleven custom states, of which six had no equivalent in the target and three were still in active use. Third, 1,100 parts existed in two revision branches created in parallel by two design offices, a situation the native bridge represents by silently keeping one.
What was corrected. The legacy mapping table was reverse-engineered and turned into an explicit resolution step in the chain, so that CAD references were rewritten rather than copied. The custom states were mapped in a workshop with the quality team, with two of them deliberately collapsed into one and the decision recorded. The parallel branches were not automated at all: they were listed, and the design offices arbitrated them one by one over six weeks.
Result. The chain ran per assembly family, in dependency order, with replay on failure. Final load: 37,800 parts and 208,000 relationships, 940 objects rejected and resolved before cutover. The acceptance test was not a load report but an engineer opening the twenty largest assemblies in the target and checking they resolved completely.
The point of this case is the proof of concept. It was not wrong, it was unrepresentative, and it had already been used to size the budget. The 500 easy parts predicted nothing about the 4,200 broken references, because they had been selected precisely for not having any.
11 PLM data migration checklist
The graph-specific checks to assign to an owner and an acceptance result.
- Inventory every source, including side CAD vaults and local reference files;
- Count objects and links, revisions per part and lifecycle states in use;
- Map every custom lifecycle state, with a business owner for each decision;
- List relationship types and verify that the migration chain preserves each required type;
- Test CAD reference resolution early on complete assemblies;
- Identify parallel revision branches and decide how to retain or reconcile them;
- Agree history depth, retrieval needs and retention requirements;
- Sequence loads by dependency and verify relationships after their objects exist;
- Validate assembly opening and structure in the target with engineers; see BOM validation;
- Reserve business arbitration time and monitor unresolved decisions in the plan.