ETIM 8 vs ETIM 9: What Changed and How to Migrate

ETIM 9.0 was published in December 2022 off the back of 4,879 change requests. If your catalogue is classified against ETIM 8, none of those changes apply themselves. The real question behind ETIM 8 vs ETIM 9 is not what the committee altered, it is what elements break in your own data when you move, and how long that move takes.

This guide covers what changed in ETIM 9, the integration points touched by a migration, and a sequence for moving a large catalogue without breaking your feeds.

Why ETIM releases new versions

ETIM is maintained by ETIM International, and the model does not stand still. New full versions land every two to three years. ETIM 8.0 arrived in November 2020, ETIM 9.0 in December 2022, and ETIM 10.0 in December 2024. ETIM 9 is already a version behind, but the same migration mechanics apply to any version step you take.

Three factors drive a new release. New product categories emerge and need classes of their own. Features get standardised so the same attribute means the same thing across markets and member countries. And obsolete classes are retired or merged into better ones.

Releases are built from requests for change submitted by members. ETIM 8.0 came from 8,780 of them. ETIM 9.0 came from 4,879. Most are small, but a handful restructure whole product groups. For the underlying model behind all this, start with ETIM classification and mapping.

What changed structurally in ETIM 9

ETIM 9.0 added 203 new classes. That is far fewer than ETIM 8.0, which added 690, most of which came from folding the proficl@ss standard into a new sector for tools, hardware and site supplies. The headline number for ETIM 9 is smaller because the work went into restructuring rather than expansion.

Restructuring is the part that affects a migration. In ETIM 9, the classes for electronic taps, the mixer type, were merged into the classes for mechanical taps. When a class is merged or retired, every product mapped to the old class needs a new home. The class ID you relied on may no longer exist.

Most of the 4,879 change requests were smaller edits to the features and values inside existing classes. A feature added here, a value renamed or deprecated there. Individually minor changes but, collectively, enough to invalidate stored attribute data.

ETIM 8.0 also introduced local standard features, which point to a national standard and carry codes like EFUK0001. Supporting them moved the IXF release format to version 3.0. If you are coming from an older implementation, that format change matters too. For a refresher on the model itself, see what ETIM is and how it works.

What an ETIM 8 to ETIM 9 migration breaks

A version migration is not a download and a restart. It breaks things in three predictable places, and each one is somewhere a product can quietly stop validating or stop syndicating without anyone noticing for weeks.

1. Classification mappings tied to old class IDs

If a product sits in a class that was merged or retired, its mapping points at nothing. Electronic tap products mapped under ETIM 8 are the obvious case, but any merged class has the same effect.

2. Feature value lookups

Where features and their permitted values changed inside a class, stored values can fall out of the allowed set. A value that validated under ETIM 8 may be rejected under ETIM 9.

3. Downstream integrations expecting the ETIM 8 structure

BMEcat exports, PIM attribute mappings, marketplace feeds and trading-partner exchanges are all built against a specific class and feature layout. Change the layout and the consumers downstream need updating in step, or they fail quietly.

Planning a clean ETIM 9 migration

A clean migration runs in a set order. Skipping a step is how catalogues end up half-mapped.

1. Map existing products to the new version: Use the difference reports ETIM International publishes for members to see which classes, features and values changed between your current version and the target.

2. Handle deprecated and merged classes first: These are the products that have nowhere to go by default. Decide the new class for each and record the old-to-new mapping.

3. Update feature and value mappings: For every class you keep, check that stored values still sit within the permitted set, and remap or clean the ones that do not.

4. Re-verify downstream consumers: Walk through each export and integration that reads ETIM data and confirm it handles the new structure before anything goes live.

5. Run in parallel before cutover: Keep the ETIM 8 output alive alongside ETIM 9 until trading partners and internal systems confirm the new feed is correct.

AI-powered ETIM migration

The slow part of any migration is re-classification. Mapping tens of thousands of products into merged or new classes by hand is where the months go.

AI classifiers change the shape of that work. Instead of a person deciding the new class for each product, a classifier reads the existing product data, the description, the attributes and the source supplier content, then proposes the correct ETIM 9 class. Deprecated and merged classes are remapped automatically, with the awkward cases flagged for a human to check rather than every product.

This is the work SKULaunch does. It reads supplier data, classifies products against ETIM, and pushes the result to destinations like Akeneo, Shopify and Magento. The same engine that classifies a new catalogue can re-classify an existing one against a newer version. For the wider picture, see ETIM mapping software and how taxonomy mapping works in practice.

ETIM 9 migration timeline and cost

Timings depend on catalogue size and how clean the source data is, but the gap between manual and AI-assisted work is large. The two numbers below are for a single migration, not an ongoing programme, and they assume your ETIM 8 mapping was reasonably complete to begin with.

A manual migration of a catalogue with 50,000 or more SKUs typically runs 6 to 18 months. The range is wide because it depends on how many classes were restructured in the products you actually carry, and how many people you can put on re-classification.

An AI-assisted migration of the same catalogue usually runs 4 to 8 weeks. The classifier does the first pass, and the team’s time goes into checking the flagged cases rather than touching every product.

These are planning estimates, not guarantees. A catalogue concentrated in heavily restructured sectors takes longer than the SKU count alone suggests. Before you commit to a date, sample a few hundred products across your worst sectors and measure the real remapping effort. The full sequence sits in the guide to implementing ETIM.

Key takeaways

• ETIM 9 vs ETIM 8 is less about new classes (203 added) and more about restructuring, including merged classes like electronic taps folded into mechanical taps.
• Migrations break in three places: mappings tied to old class IDs, feature values that fall out of the permitted set, and downstream integrations built for the old structure.
• Work in order: map to the new version, handle deprecated classes, fix value mappings, re-verify consumers, then run in parallel before cutover.
• Manual migration of a 50,000 SKU catalogue runs months; AI-assisted re-classification brings that down to weeks.
• ETIM 10.0 is now current, but the same migration steps apply whichever versions you are moving between.

Planning a move to ETIM 9, or straight to ETIM 10? SKULaunch re-classifies your existing catalogue against the new version, remaps merged and deprecated classes automatically, and flags only the cases that need a human. Book a demo with us, bring your worst sector, and watch the remapping live before you commit.