Validating a migrated BOM: compare the structure and test the assembly

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.

The load had reported no failure. The counts were right. Validation was incomplete.

A file that arrives intact is not a migrated part

A successful load verifies whatever the loading mechanism checks. It does not replace validation of relationships and usage, in either ERP or PLM.

An ERP cost centre is not self-contained: its assignments and validity must be consistent. SAP documents company code, profit centre and hierarchy assignments in its cost centre master data.

In PLM, checks cover components, drawing and part associations, and revisions. A byte-identical file can remain unusable if its references do not resolve in the target. Tools can support these structures; verify their coverage against the actual scope.

The load report remains necessary evidence. Used as the sole acceptance criterion, it leaves the following checks unanswered.

References must resolve in the target

Depending on the CAD tool and its PLM integration, component resolution relies on identifiers, file names, locations or managed relationships. A change in vault or resolution rules can break references even when the files are present.

The chain must preserve or transform references as the target requires, then verify their resolution. Rewriting every reference is not a universal requirement. The cases to handle remain concrete: files moved between vaults, undocumented historical mappings, objects excluded from scope but still referenced.

Some defects are detected during loading or check-in. PTC states that required incomplete CATIA V5 dependents can block upload and check-in; preferences affect this behaviour. Other discrepancies escape those checks. Establish what the actual connector detects, then test resolution in the target environment.

Four levels, applied to a graph

The four levels of testing complement one another: each answers a different question.

Objects accepted. The load report identifies accepted objects, rejects and the checks performed by the loader. It does not establish compliance of the entire structure on its own.

Counts reconcile. Reconcile objects and relationships, accounting for approved transformations and exclusions. For example, 208,000 expected links and 204,000 loaded links leave 4,000 links to explain, even if object counts balance.

Structures conform. Automatically compare source and target BOMs in equivalent configurations, under the approved mapping. Compare relationships and their attributes, not just the presence of child parts.

The product behaves. Verify CAD resolution and business processes in the target. Parts of these tests can be automated; engineers complete acceptance with the uses and business decisions that technical checks do not establish.

For example, Creo TOOLKIT supports programmatic model retrieval. PTC warns that a successful retrieval return can conceal components suppressed or frozen after an error: retrieval errors must also be collected. Automation must inspect the result, and its coverage depends on the available CAD interfaces.

Comparing two explosions, line by line

A central automated check exports the multi-level explosion from source and target, then compares the expected rows after transformation.

First define the configuration to compare. Windchill configuration specifications select versions using criteria such as view, state, baseline or effectivity. Comparing extracts produced under different filters can create a discrepancy or conceal one.

Four precautions make the result usable:

• 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.
• Fix equivalent configurations, including expected revisions and iterations, view, options and effectivity applicable to the scope. Record approved transformations where the models differ.
• Compare each occurrence within its parent path. Mapped child identifier, expected revision or iteration, quantity, unit, position and effectivity must follow the agreed rules. The same component in the wrong place remains a defect.
• Normalise ordering and formats before comparing, without discarding repeated occurrences or meaningful differences.

Run these checks on every top-level assembly and every configuration in the agreed scope. Object, relationship and attribute reconciliation also covers objects outside those assemblies. The manual acceptance sample complements this complete coverage. Each discrepancy must be corrected or covered by an explicitly approved, recorded exception before cutover.

Lifecycle states that survive the load but not the process

A valid target state does not prove that the part’s permitted uses have been preserved.

If the source has eleven states and the target six, some mappings require a business decision. An object can then load in a technically valid state while losing a business restriction.

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.

Have business owners validate the mapping, then automatically check every object’s expected state against its source state and applicable conditions. Comparing against a faulty mapping will not detect the faulty decision.

Add process walks covering the relevant states, transitions, roles and site restrictions. Some scenarios can be automated; engineers also verify that the offered permissions and uses match the actual business need. One part per state is enough only where the other conditions do not introduce different behaviour.

Choose acceptance assemblies according to risk

Manual acceptance capacity is limited. Twenty assemblies may be a starting set, not a coverage standard. Selection must cover the product families, configurations and risks in scope, then expand if the defects found warrant it.

Include:

• the deepest structure in the estate, whatever it is;
• the assembly with the most components;
• assemblies covering parts from every source vault, if there is more than one;
• components carrying each of the mapped lifecycle states, especially merged states and site restrictions;
• critical configurations and effectivity, including variants and revision changes;
• 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.

Record the risk covered, configuration opened and expected result for each case. A set containing only easy assemblies leaves difficult cases without evidence: the same trap as validating on a clean sample. This selection does not reduce the scope of automated checks.

What validation cannot recover after go-live

A defect discovered after cutover may already have produced derived data, in both ERP and PLM.

In PLM, an error may surface only when someone opens a model, months after cutover. By then, engineering changes, new revisions and downstream manufacturing data may rest on the migrated structure. Correcting the original object does not automatically correct what was derived from it.

The dry run therefore needs the complete comparisons, resolution tests and business acceptance of assemblies. Deferring those checks to hypercare also defers discovery of the dependencies that need correcting.

The acceptance criterion to write into the plan

Write a criterion that covers the different levels of evidence:

Automated checks reconcile objects, relationships and attributes across the full scope. Explosions of every top-level assembly and every agreed configuration match the source after mapping: parent path and occurrence, identifier, revision or iteration, quantity, unit, position and effectivity. States match the validated business mapping. No blocking discrepancy remains open; any exceptions are approved and recorded.

CAD resolution tests verify the expected components and reported errors. Each assembly in the acceptance sample, selected according to risks and product families, opens and resolves every expected component in the intended configurations, then passes the expected business uses. Process walks cover the relevant states, transitions, roles and restrictions. This acceptance testing complements automated checks across the entire scope.

The acceptance record must identify the extracts, comparison rules, results and approvers. 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.

If you do not yet know how many relationships your product structure contains, or how many references no longer resolve, a readiness audit measures that before a schedule is committed.