Legacy Product Data Is Not a Migration Problem

Legacy product data is treated as a migration problem — lift it into the new system and move on. But the data carries relationships, context and tribal knowledge that a system migration does not preserve. It is an authorship problem, not a migration problem.

Legacy product data is routinely treated as a migration problem: move it from the old system to the new one, clean it up along the way, and move on. But the data’s real problem is not where it lives — it is what it is missing. Supersession chains, cross-references, product identity and applicability are authorship gaps, not format issues. A migration moves the mess. Authorship fixes it.

Every ERP migration, every PIM implementation, every catalog re-platform starts with the same conversation: “We’ll clean the data during the migration.” Five months later, the data is in the new system. It is structurally valid. It passes the import checks. And it has exactly the same problems it had before — because the problems were never format problems.

What migration actually does

A migration moves records from system A to system B. Along the way, it may:

Transform field formats (date formats, unit abbreviations, encoding)
Map columns from the old schema to the new schema
Deduplicate exact matches
Validate required fields
Normalize capitalization and whitespace

This is useful work. It is also ETL work — extract, transform, load. It changes the container; it does not change the content.

What migration does not do

A migration does not create data that was never in the old system:

Supersession chains. If the old system had a flat “old part / new part” column that was last updated by someone who left in 2022, the migration faithfully moves that flat column into the new system. The chain is still one hop deep, the source field is still empty, and the date field is still blank. The new system’s schema may have fields for all of these things, but the migration cannot populate them.

Cross-references with evidence. If the old system had a two-column spreadsheet linking OEM numbers to aftermarket numbers without a relationship type, a confidence level, or a source, the migration produces the same two-column list in a new table. The new system can store evidence; the migration does not create evidence.

Product identity. If the old system has three records for the same product under three different supplier part numbers, the migration creates three records in the new system. Deduplication on exact match catches some duplicates, but identity resolution across different numbering schemes, abbreviations and format variants requires matching logic and human review, not ETL.

Applicability data. If the old system stored fitment as a free-text note (“fits XR-700”), the migration moves the note. It does not parse it into a structured record with make, model, serial-range start, serial-range end and source.

The authorship gap

The difference between migration and authorship:

	Migration	Authorship
What it does	Moves data from one system to another	Creates the relationships, evidence and context that make the data trustworthy
Input	Records in the old system	Records plus domain knowledge, manufacturer documentation, supplier feeds, product specialist expertise
Output	The same data in a new format	Resolved product identities, typed relationships, sourced cross-references, structured applicability
Who does it	Data engineers, integration team	Catalog team, product specialists, domain experts — supported by matching and resolution tools
When it is done	When the import succeeds and the validation passes	When a search for any part number — current, legacy, customer-specific — returns the right product with evidence
Typical duration	Weeks to months	Ongoing

The authorship gap is the reason that post-migration disappointment is so common. The team expected the new system to fix the data problems. The new system fixed the format problems. The data problems — missing relationships, unresolved identities, unsourced cross-references — carried over intact.

Why the framing matters

If legacy data is a migration problem, the solution is a migration project with a start date and an end date. If legacy data is an authorship problem, the solution is a continuous process with tooling that makes authorship faster and more reliable.

The migration framing leads to:

A one-time cleanup sprint that creates a “golden dataset” that begins drifting the moment the sprint ends
An expectation that the new system will prevent the old problems (it provides the fields; it does not fill them)
A handoff from the migration team to the operational team with no ongoing authorship workflow

The authorship framing leads to:

Tooling for ongoing identity resolution, cross-reference management and supersession tracking
A workflow that processes every new supplier feed, every price-list change and every engineering change notice as authorship input
An expectation that data quality is a rate, not a state — measured by how fast new inputs are resolved, not by a one-time score

Where Claro fits

Claro treats legacy product data as an authorship problem. When a migration delivers 500,000 records into a new system, Claro resolves their identities, links them through supersession chains, builds cross-references with typed relationships and evidence, and structures applicability data — not as a one-time project, but as an ongoing process that runs every time new data arrives. The migration gets the records into the system. Claro makes them trustworthy.

Glossary

Spare Parts Data Glossary

All spare-parts data terms in one table.

Guide

Model supersession chains

The data model for supersession: chains, splits, merges.

Article

Supersession: the most under-modeled relationship

Why catalogs still hold supersession in people's heads.

Glossary

What is supersession?

When a manufacturer replaces one part number with another.

FAQ

Why is legacy product data not a migration problem?

Because migrating data from one system to another preserves the data as-is — it does not add the relationships, evidence and context that the data was missing in the old system. Supersession chains, cross-references, applicability data and product identity are authorship work, not ETL work. A migration moves the mess; it does not fix it.

What is the difference between migrating and authoring product data?

Migration is moving records from system A to system B with format transformations. Authoring is creating the relationships, evidence and context that make the records trustworthy: resolving identity, linking supersession chains, building cross-references with sources, and structuring applicability data. Most legacy product data problems are authorship gaps, not migration failures.