Validating a migrated BOM: opening the assembly is the test

Thirty-eight thousand parts, two hundred and eight thousand relationships, load report green. The migration team presented reconciliation counts that balanced to the record: every object out of Windchill, every object into 3DEXPERIENCE, zero rejects on the final pass.

Three weeks later a design engineer opened the top-level assembly of the main product line. It resolved 340 of its 412 components. The other 72 were present in the system, correctly, with all their attributes, and the assembly could not find them.

Nothing had failed. The counts were right. The test was wrong.

A file that arrives intact is not a migrated part

This is the difference between an ERP migration and a PLM one, and it is worth stating plainly because it drives everything else.

An ERP record is largely self-contained. A cost centre is correct or incorrect on its own terms, and if it loads with the right values, it is migrated.

A CAD model is a set of pointers. Its value is in what it references: child components, drawings, the part it represents, the revision it belongs to. A model that arrives byte-identical but whose pointers do not resolve in the target vault is not a migrated part. It is a file. The native tools problem is exactly this: they move files well and rebuild structure badly.

Which means the load report, the thing every programme uses as acceptance, measures the one property that was never in doubt.

Cross-file references have to be rewritten, not copied

The mechanism deserves a sentence, because it explains why the failure is invisible until someone opens something.

A CAD assembly stores references to its children by some combination of identifier and location, and the resolution rules depend on the vault structure and the tool’s search path. Move the files to a target whose structure differs, copy the references unchanged, and each individual file is perfect while the graph between them is broken.

The migration chain has to resolve and rewrite every reference against the target’s addressing scheme. That is a real transformation step, with its own failure modes: references pointing at files moved between vaults years ago, references resolved in the source through a legacy mapping table nobody documented, references to objects excluded from scope.

None of those produce a load error. They produce a file that arrives, and an assembly that does not open.

Four levels, applied to a graph

The four levels of testing apply here too, but the useful ones sit higher up.

Objects accepted. The load report. Necessary, proves nothing about structure.

Counts reconcile. Objects out equals objects in. Do the same for relationships, which is the level most PLM programmes skip: 208,000 links out and 204,000 links in is a balanced object count and a 4,000-link hole. On a product structure, the link count is the meaningful volume.

Structures resolve. For a given part, does its bill of materials in the target contain the same children, in the same quantities, at the same levels as the source. This is comparable automatically and it is where most real defects are caught.

The product behaves. An engineer opens the assembly in the target tool and it resolves completely. This is the only level that tests the CAD reference rewriting end to end, and it cannot be automated away.

Comparing two explosions, line by line

The highest-value automated check on a PLM migration: export the multi-level BOM explosion for a part from the source, export it from the target, and compare.

Three details make it work rather than produce noise:

• Compare the explosion, not the first level. A first-level comparison passes while a child three levels down has lost its own children. The defect you are hunting is depth-dependent.
• Compare the tuple, not the identifier. Child identifier, quantity, unit, position and effectivity. A structure where the right children appear with the wrong quantities is a structure that will produce wrong purchase orders.
• Normalise the sort before diffing, or every comparison fails on ordering and the real differences drown.

Run it on the full set of top-level assemblies, not a sample. It is cheap once written, and it is the check that turns “the migration looks fine” into a number.

Lifecycle states that survive the load but not the process

A separate class of defect, and one that automated comparison misses entirely.

Custom lifecycle states rarely map one to one. Your source has eleven, the target has six, so some are merged and some are approximated. That mapping is a decision, and once made, the objects load with a valid target state. Nothing flags anything.

The problem appears later, in the process. A part migrated into “Released” that was actually in “Released, pending site validation” is now consumable by manufacturing, three weeks earlier than it should be. The data is valid. The business state is wrong.

The test for this is not a data comparison, it is a process walk: take one part per mapped state, run it through the workflow it would normally follow in the target, and check the transitions available to it are the ones its real state should allow. A dozen parts, one afternoon, and it catches a class of defect that no reconciliation will.

Choosing the twenty assemblies

Manual validation does not scale, so the selection is the whole game. Twenty assemblies chosen well beat two hundred chosen conveniently.

Pick for difficulty, not for representativeness:

• the deepest structure in the estate, whatever it is;
• the assembly with the most components;
• one that includes parts from every source vault, if there is more than one;
• one whose components carry each of the mapped lifecycle states, especially the merged ones;
• structures containing the oldest parts, created under conventions nobody remembers;
• any part known to exist in parallel revision branches;
• the assemblies from the highest-revenue product line, because business risk is a legitimate criterion alongside technical risk.

That list is deliberately adversarial. A validation set chosen for being easy to check tells you your code compiles, which is the same trap as validating on a clean sample.

What validation cannot recover after go-live

The reason this matters more on PLM than elsewhere: the cost curve is steeper.

An ERP error surfaces fast, on the invoice run or the month-end close, and the wrong data has usually not been built on. A PLM error surfaces when someone opens a model, which may be months after cutover, and by then engineering changes, new revisions and downstream manufacturing data rest on the migrated structure. Correcting the original object no longer corrects what was derived from it.

That asymmetry is why PLM validation is worth doing before cutover at a level of thoroughness that looks excessive, and why the dry run has to include the manual assembly checks rather than deferring them to hypercare.

The acceptance criterion to write into the plan

Replace “load report shows zero rejects” with something that can actually fail:

The twenty selected assemblies open in the target system, resolve every component, and their multi-level explosions match the source on identifier, quantity, unit and position. One part per mapped lifecycle state passes a process walk in the target.

It is specific, it is testable, and it is the difference between a migration that was measured and one that was reported. The rest of the sequence is in the PLM data migration guide, and the arbitration time this validation generates belongs in the plan as its own workstream.