Migrating off a PLM without losing your history

Decide what history means before you export anything

The first question is not technical. How far back does your history need to go, and in what form? There are three honest answers and they cost very different amounts.

Current state only. Parts, released structures, current revisions, open changes. This is fast, it covers everything a person does day to day, and it loses the record of how you got here.

Current state plus released history. Every released revision, with the change that produced it. Enough to answer what a unit shipped with, which is the question that justifies a PLM at all. This is the right answer for most organisations.

Everything. Including iterations, abandoned concepts and rejected changes. Almost always a mistake — it triples the migration and imports a quantity of noise that makes search worse for years.

Whichever you pick, say it out loud and write it down. Migrations fail because two people assumed different answers and discovered it at cutover.

The five stages

A migration that can only be run once is a migration nobody dares test. The whole design goal is repeatability.

• Extract — pull from the source through a named path per system, rather than a generic CSV importer that treats every tool as a spreadsheet.
• Map — bind each source field to a target type. Unmapped fields are reported rather than dropped silently, because a field you did not know existed is exactly the one somebody depended on.
• Validate — check the mapped data against the target model. Errors must name rows, not counts. “4,412 errors” is useless; “row 4,412: part 510-0090 has quantity 8 EA in a numeric column and three reference designators listed” is actionable.
• Deduplicate — find the same part arriving under two numbers, matched on manufacturer part number then internal number. Never on description similarity: a wrong merge is close to unpickable.
• Commit — one transaction. Either the run lands completely or nothing does, and the whole run is reversible in one action afterwards.

What does not come across, and why

Being clear about this early is the difference between a successful migration and a disappointing one, because the gaps are discovered either now or at cutover.

Distinctions the source never made. If the old system had one version field, the difference between released revisions and in-progress saves was never recorded and cannot be reconstructed. You import what exists and the finer model starts applying from that point forward.

Effectivity, usually. Most tools store an effective date as a note on a change or a text field on a line. Where it was structured you can map it; where it was a note, somebody has to decide what it meant, and that is engineering judgement rather than a mapping rule.

Relationships that lived in documents. A part related to a requirement by a sentence in a specification is not a relationship a migration can find. It becomes one when somebody records it.

Approval history, partially. Who approved what usually survives; the meaning behind it — approved, abstained, delegated — usually does not, because the source recorded a boolean.

Duplicates are the real work

Every migration surfaces them and every organisation underestimates how many. Three internal numbers for one M3 screw is normal, not embarrassing — it happens because search failed somebody at the moment they needed a part and creating one took twenty minutes.

The temptation is to clean up during the migration. Resist most of it. Merging is irreversible in a way importing is not: two genuinely different parts merged into one takes the referencing structures with it, and the record of which was which is gone.

The workable sequence is import the duplicates, surface them as candidates with evidence, and consolidate afterwards through the normal change process — where each consolidation has an impact set, an approver and a rollback. Slower on paper, and it is the version that finishes.

The exception is exact duplicates with no distinct history — the same part imported twice from two exports. Those are safe to merge at import because there is nothing to lose.

Settle identity with the ERP first

The failure that costs a quarter is importing a parallel item master and reconciling it afterwards. Your ERP already holds items — including many the PLM never created: packaging, freight, consumables, services.

So item identity is matched on the way in, on manufacturer part number first and internal number second, with anything unmatched surfaced for a person rather than merged on a score. That turns a reconciliation project into a finite list you work through before go-live.

It also forces the ownership conversation early, which is the right time to have it. Which system masters the part number, which masters cost, which owns the MBOM — those answers should exist before data moves, not after.

Run it more than once

The single best predictor of a migration going well is how many times it was rehearsed. Not because the data changes much, but because the *decisions* do — mappings get refined, validation rules get tuned, and duplicates get triaged.

So run into a sandbox, look at the result with the people who will use it, throw it away, and run again. Then run a delta close to cutover so the gap between the rehearsal and the real thing is days rather than months.

A migration you can only afford to run once is one where every decision has to be right first time and nobody finds out until it is too late to change. That is a services engagement risk profile, and it is why building migration as product matters more than any individual mapping rule.

Rehearsal also settles the argument about scope. A team looking at their own data in the new system, with the history they chose to bring, decides much faster whether that was the right amount than any workshop about it will. Two of the three decisions at the top of this page are usually revised after the first rehearsal, and that is the rehearsal working rather than failing.