Brownfield Is the Default: Why PIM Projects Fail at the Migration, Not at the Destination

You can plan beautifully on a greenfield site. No company has ever stood on one.

Every PIM demo you have ever seen was a greenfield project: a clean catalogue, a consistent attribute set, a category tree that looks like someone designed it. Your assortment looks different. It has fourteen years of history, three generations of Excel, an ERP that became the master data system by accident, and a supplier feed nobody has touched since 2019 — because nobody knows what happens if they do.

That is not the exception. That is the default.

The decisive question in a PIM project is not which system is best. It is what happens to the data you already have.

PIM projects rarely fail on the software

When a PIM project collapses, it almost never happens in the feature comparison. It happens in the migration.

The numbers are uncomfortably clear: according to Gartner, 83 percent of all data migration projects either fail or exceed their budgets and timelines. Not 83 percent of software selections — of migrations.

The reason appears in no project plan. It is migration debt: the sum of every legacy problem you would have to carry over for the new system to work on day one. Migration debt never shows up as a budget line, because it cannot be estimated honestly before the project starts. It only becomes visible when someone tries to map the old data model onto the new one — and discovers that the old data was never meant to be understood. It was meant to be stored.

The three legacy burdens that make every brownfield project expensive

First: attribute chaos. The same information sits in six fields under five names. “Colour”, “Farbe”, “col_1”, “base_colour”, plus a free-text field where someone started maintaining colour families in 2021. The values are just as heterogeneous: “S”, “s”, “Small”, “36/38”. Technically this is trivial to migrate. Semantically, it is the actual work.

Second: the category tree. It was not designed, it grew. It contains marketing logic, logistics logic, a retired tax logic, and at least one node that exists only because a key account wanted a special report in 2018. Nobody in the company can say what every node means. A new system forces you to answer exactly that.

Third: the data gaps. These are the insidious ones, because they are invisible in the legacy system. The old PIM never flagged them, because it never required them. The moment you map your assortment against a clean target model with mandatory attributes, it becomes visible that 40 percent of your articles have no reliable technical data. That gap was always there. It was simply never measured. Gartner puts the cost of poor data quality at an average of USD 12.9 million per organisation per year — most of which accrues long before anyone starts thinking about a migration project.

The big bang is the risk, not the goal

The classic PIM project is scoped around a cutover date. Everything has to be right on day X: every attribute mapped, every category translated, every gap closed, every channel switched over.

Picture a retailer with 38,000 articles and a go-live planned for September. In July it turns out that the categories for two marketplaces need to be cut differently than planned. The options now are: miss the date, cut the scope — or go into the Christmas season with half-finished data. All three are bad, and all three follow from the same decision: putting everything on one date.

McKinsey studied this in banking and arrives at a pattern that holds across industries: organisations that integrate first and simplify second cut typical transformation timelines in half and reduce costs by up to 70 percent — for the same outcome.

A cutover date is not a project method. It is a bet.

The third option: complement instead of replace

Between “nothing changes” and “we replace the legacy system” sits the option that almost never appears in an RFP: ainavio as a complement to the system you already run.

The legacy system keeps what it does well. The ERP stays master for prices, stock and commercial master data. The old PIM stays in operation as long as it is needed. Alongside it, ainavio takes over the part where the legacy system actually fails: onboarding new products, AI-driven enrichment, category and attribute mapping to channels and marketplaces, publishing. Connected through REST API and connectors, in both directions, with a Golden Record in which you define per attribute which source takes precedence.

For some customers that is the target state: an agentic layer over a landscape nobody wants to touch. For others it is the migration path. They start with one product area and one channel, pull the next area across, and then the next — and after twelve months they notice that the legacy system is an ERP again. No cutover weekend. No cutover date.

What getting started actually looks like

This is where brownfield projects usually stall: before the new system can deliver anything, the customer is expected to clean up their legacy data first. We reverse that order.

We run the initial onboarding together with you — not as homework you have to finish beforehand:

1. Raw data in, uncleaned. Export from the legacy system as CSV, Excel, via API or as a PDF catalogue. No clean-up up front.
2. Mapping. The Mapping Agent maps source fields onto target attributes and normalises values — “Small”, “s” and “S” become one value, colour variants become one colour family.
3. Creating categories. The Classification Agent proposes categories and product families and assigns your articles. Your old tree is not copied blindly; it is held against a new proposal. You decide node by node.
4. Making the gaps visible. The Quality Agent finds missing mandatory attributes, duplicates and inconsistencies. From that point on, the gap list is a work plan rather than a surprise.
5. Closing the gaps. The Research and Enrichment Agents source missing information from manufacturer and supplier material, PDFs and images — every attribute with its source and a confidence score, so nothing is quietly invented.
6. Publishing. The Publishing Agent validates against each channel’s requirements before anything is exported.

The metric that matters here is not the go-live date. It is Time to First Product: how long it takes until the first product actually reaches a channel through the new system. In a big-bang project that number is identical to go-live and sits nine months out. With a complementary start it is measured in days. At SDS Swiss Dental Solutions the complete PIM project, including the Business Central and Shopify connections, was live in under six weeks.

Back to the renovation

You do not demolish a building people work in just to rebuild it. You renovate it while it stays in use: floor by floor, with a site you can cordon off, and a state you could stop at any time without the building becoming uninhabitable.

That is precisely the property the classic PIM project lacks. It has no intermediate state you can stop at. It has only a before and an after — and, in between, a risk nobody can size honestly.

A PIM project does not have to begin with a move. It can begin with the first product.