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.
What gives a PLM its value is not the files. It is the links: references between parts, bills of materials, associated CAD documents, maturity states, dependencies. Copying the files without rebuilding those links means delivering parts that no longer know which product they belong to. That is exactly what native tools do.
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: migrating the latest released revision costs ten times less than the full history. The right answer depends on your regulatory obligations. It is a business decision, not a migration defect.
04 Two PLMs never describe the product the same way
Windchill thinks in WTParts, CAD documents and relationships. 3DEXPERIENCE, built on ENOVIA, thinks in Physical Products, references and its own maturity states. Native tools assume a 1:1 mapping between these worlds; that mapping does not exist. It has to be built, attribute by attribute, state by state, link type by link type.
And that mapping cannot be read in any documentation: it lives in accumulated customizations, specific lifecycles and team conventions that were never written down. It is business modeling work as much as technical work. That is also why a dedicated migration consultant works alongside every project.
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.
A PLM specificity: the data almost never comes from a single source. Several instances, side CAD vaults, spreadsheet exports that quietly became the real reference... The audit must map and confront all the sources, not photograph the cleanest one.
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 once every structure has already been rebuilt and validated.
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 What it costs, and what it prevents
The orders of magnitude match the ERP side: dedicated expertise between €200,000 and €1 million depending on scope, against fiascos that run into tens of millions. With one PLM-specific aggravating factor: a corrupted product structure is discovered late, with the first assembly an engineering office can no longer open.
Duration depends on the number of objects, links and sources to reconcile. The audit is what makes the estimate reliable. Answers to the most frequent questions are on the methodology page.