ECLASS Version Migration Playbook
A five-step workflow to migrate a catalog between ECLASS releases: inventory, map class and property deltas, detect drift, migrate with evidence, verify. Includes an EPD data section.
To migrate a catalog between ECLASS releases: inventory the current classification state, map the class and property deltas between the two releases, identify which assignments have drifted, migrate them with evidence, and verify against the new release. Do this per delta, not per catalog.
A new ECLASS release changes the target your assignments point at. ECLASS Release 17.0 is in development at the time of writing, with release planned by the end of November 2026, so the work below is the preparation. Re-check the release status and the published change list before you start. The effect on a catalog is classification drift: assignments that were right become wrong without anyone editing them.
- 1. Inventory the current classification state
Export every SKU with its ECLASS class, the release it was classified under, the property values and the source of each. Records without a recorded release or source go on a separate list, because you cannot map them reliably.
- 2. Map class and property deltas between releases
From the release documentation, list the classes that were added, removed, split, merged or renamed, and the properties that changed. The output is a table of old class to new class(es) with the rule that applies.
- 3. Identify drift
Join the inventory to the delta table. SKUs whose class is unchanged are done. SKUs in a class that was split or merged need a decision, and SKUs whose properties changed need new values.
- 4. Migrate with evidence
For each SKU that needs a decision, assign the new class from the product’s datasheet, not only from the old class. Record the source and the confidence, and route low-confidence calls to review. Write the result back to the PIM or ERP only once it carries that evidence.
- 5. Verify
Validate the output with the ECLASS validator, compare class counts before and after, and sample-check the split classes by hand.
Environmental data: EPD workflow
If your buyers ask for Environmental Product Declaration (EPD) data, make it a step in the same migration rather than a separate project. Check whether the release you are moving to defines properties for EPD data, then:
- List which SKUs have an EPD document and which do not.
- Record the document, its issuing programme, and its validity dates for each.
- Map the EPD fields to the properties the new release provides, and mark any field without a source as an evidence gap.
Do not assume a release carries EPD properties until you have confirmed it in the release documentation.
Related
Guide
Classification drift
How to detect, measure and stop it.
Playbook
Validate ECLASS in BMEcat
Check an ECLASS export before it ships.
Glossary
ECLASS IRDI
How ECLASS identifies classes and properties.
FAQ
How do I migrate a catalog to a new ECLASS release?
Inventory your current class and property assignments, map the class and property differences between the two releases, find the assignments that have drifted, migrate them with the evidence for each change, and verify the result against the new release.
Why do ECLASS releases create classification drift?
A new release can split, merge or rename classes and change properties. Products assigned under the earlier release then point at a class or property that no longer matches the standard.
Should I re-classify the whole catalog for each release?
No. Map the deltas first and re-classify only the products whose class or properties changed. Re-classifying everything repeats work and discards decisions that were already correct.
Claro
See how Claro handles this in production
This concept is one piece of keeping a catalog trusted. See how Claro resolves identity, enriches missing attributes, and validates every update before it reaches your PIM or ERP.
Learn more