ETIM 11.0 Migration Regression Checklist

A new ETIM release moves the target your classification points at. ETIM International plans ETIM 11.0 for release on 1 December 2026, having reserved until 15 October 2026 to process open change requests, with a beta expected around November 2026. The beta is your test window: run this checklist against it so the migration is proven before 11.0 is final. Re-check the published dates and change list before you start — release schedules move, and the current released standard is still ETIM 10.0. The risk if you do nothing is classification drift: assignments that were correct under ETIM 10.0 become wrong without anyone editing them, and exports built for the old model start failing validation.

This is the ETIM counterpart to the ECLASS version migration playbook; run them the same way, and read the two together if you maintain both standards. Both are projections of the same underlying product facts — the point of keeping one trusted product record rather than re-deriving each standard by hand.

The regression checklist

1. 1. Diff the release: classes, features, values

   From the ETIM 11.0 change documentation, list what changed against ETIM 10.0: classes added, removed, split, merged or renamed; features changed or retyped; and value lists altered. The output is a delta table of old class and feature to new, with the rule that applies to each. Do not start remapping until this table exists.

2. 2. Identify the impacted SKU classes

   Export every SKU with its ETIM class, the release it was classified under, its feature values, and the source of each. Join that inventory to the delta table. SKUs in an unchanged class are done; SKUs in a split, merged or renamed class need a decision; SKUs whose features or value lists changed need new values. SKUs with no recorded release or source go on a separate list — you cannot migrate them reliably.

3. 3. Map against your current BMEcat and xChange exports

   For each impacted class, check how it appears in the formats you actually publish — BMEcat catalogue files and ETIM xChange product data. Confirm the class code, feature codes and value codes you emit still resolve under ETIM 11.0, and note every field that will need a new code. If you receive the ETIM model as an IXF file, load the 11.0 model first so you are mapping against the real release, not a guess.

4. 4. Regression-test imports and exports

   Run representative files through the full round trip against the 11.0 model: import your CSV and Excel supplier sheets, build a BMEcat and an xChange export, and validate each. Compare the pass/fail result and the class and feature counts against the ETIM 10.0 baseline. A file that validated under 10.0 and fails under 11.0 has found a real delta to fix, not a tooling error. Check whether your validation tooling — for example an ETIM validator — already supports the 11.0 model; confirm its version coverage rather than assuming it, and do not treat a tool that only knows 10.0 as proof the export is clean.

5. 5. ETIM xChange 2.0 mapping notes

   If you exchange product data in ETIM xChange, work against version 2.0 (released 27 November 2025), which carries expanded environmental and packaging data on top of the classification payload. Map each changed ETIM 11.0 feature to its xChange field, and keep the two version decisions separate: the classification model is ETIM 11.0, the exchange format is xChange 2.0. Validate a sample xChange file against its schema after remapping.

6. 6. Stage changes through a review queue

   For every SKU that needs a decision, assign the new class and values from the product’s datasheet, not only from the old class. Record the source and a confidence score, and route low-confidence calls to human review instead of writing them straight through. Only values that carry evidence reach the PIM or ERP.

7. 7. Version and keep a rollback

   Keep the ETIM 10.0 assignments and exports beside the 11.0 ones, not on top of them, with the release stamped on each record. If a mapping turns out wrong after go-live, you can fall back to the prior version and re-run the affected classes rather than reconstructing them from memory.

Related

FAQ