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 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 the three cutover strategies on a PLM estate | Strategy | Typical duration | Rollback risk | Relative cost | Where it works | Where it breaks |
|---|
| Big bang | One window, a weekend to a week, after months of rehearsal | High. Engineering stops until structures are verified, and verification is slow | Lowest if the graph is clean | A single PLM instance, one CAD tool, one coherent numbering scheme | Cross-file CAD references. A broken assembly is found by an engineer on Monday, not by the load report on Sunday |
| Phased | Several months, one wave per product line or per site | Contained, provided a wave contains whole assemblies | Higher: two repositories live, and a rule for which one owns a shared part | Product lines that are genuinely independent, or a site with its own numbering | Shared components. A standard fastener used across every product line belongs to every wave, so it belongs to none |
| Trickle | Continuous, often over a year | Low per object, high on the graph. A structure half-migrated is a structure that is wrong | Highest: continuous synchronization of a versioned object graph | Long coexistence, ongoing projects that cannot be frozen mid-development | Revisions created on both sides. Two parallel revision branches of the same part rarely merge back cleanly |
09 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. These are ranges observed on our own engagements and in published programme costs, not a rate card.
What moves a PLM migration within that range is rarely the object count. It is the number of distinct link types and custom lifecycle states to map. A repository of 50,000 parts with a standard lifecycle costs less than one of 15,000 parts carrying eleven custom states, four relationship types added over the years, and two CAD tools in the same vault.
With one PLM-specific aggravating factor on the failure side: a corrupted product structure is discovered late, with the first assembly an engineering office can no longer open. An ERP failure surfaces on the invoice run, within days. A PLM failure surfaces when someone opens a model that was migrated three months ago, and by then thousands of downstream changes rest on it.
Duration depends on the number of objects, links and sources to reconcile. The audit is what makes the estimate reliable. Our data migration services page sets out what is covered at each phase, and what is not.
10 One case, anonymised: 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 version. Every item here has cost someone a schedule slip.
- Inventory every source, including side CAD vaults and the spreadsheet that quietly became the real reference for one product line;
- Count links, not just objects. Relationships per part, revisions per part, states in use. The link count sizes the work far better than the object count;
- List every custom lifecycle state and mark which are still in active use. Each one needs a mapping decision and an owner to make it;
- Enumerate relationship types added over the years. Standard bridges handle the standard ones and drop the rest without saying so;
- Test CAD reference resolution early, on real assemblies, not on individual files. A file that arrives intact but cannot resolve its children has not been migrated;
- Find the parallel revision branches before the tool picks a winner for you;
- Decide the history depth explicitly: latest released revision, or full history. The cost difference is roughly tenfold and the answer is regulatory, not technical;
- Respect dependency order in the load: parts, then structures, then documents, then attachments. A bill of materials loaded before its parts fails, and fails late;
- Validate by opening assemblies in the target system, with an engineer, not by reading a load report;
- Reserve arbitration time from the business, in the plan, in weeks. It is always the critical path and never the line item anyone budgets.