PIM vs ERP: where product data should live when you switch systems

An ERP runs the hot, transactional side of your business: stock, orders, purchasing, finance. A PIM (product information management) holds the product record itself: attributes, content, media, and everything each sales channel expects, and it manages how that record appears across your channels. In short: an ERP is an operational tool. A PIM is a commercial one.

The reason they stay separate systems is cadence. Stock and orders change with every sale, so they need low-latency pipelines built for transaction throughput. Product data changes on a schedule: you enrich it, review it, publish it, then leave it alone until something about the product changes. Cold data and hot data want different architectures, which is why a system optimised for one tends to be mediocre at the other.

A simple way to keep the boundary straight: ask who authors a field, not what type of data it is. The system your team opens to change something owns it. Everything else reads it. Your ERP is where someone books in stock; your PIM is where someone rewrites a product description or maps a colour attribute for a marketplace.

Partly. Every ERP holds a product record, and for some businesses that record is genuinely enough. If you sell through one single channel and have no objective to expand into more, the ERP's item card plus your webshop's product pages can carry you a long way. The same is often true for a small, high-touch range where every listing is tuned by hand per platform. There is no rule that says every business needs a PIM, and anyone telling you otherwise is selling one.

What does enough look like? An item card carrying SKU, name and price, a webshop where the descriptions and images live, and one team touching one channel. Plenty of profitable businesses run exactly that way. The calculation only changes when a second channel arrives and the same product suddenly needs to be correct in two places that want different things.

Some ERPs are also better at this than their reputation suggests. Microsoft's Business Central has typed item attributes, variants with their own attributes and pictures, and a genuinely deep Shopify connector. The bigger Dynamics 365 stack even contains a module literally named Product information management. This is worth saying plainly, because the honest question is not whether an ERP can hold product data. It can.

The question is what happens in a multichannel world. The jobs operators tend to expect from the ERP are descriptions, attributes, prices and media, and this is where most ERPs run out. Each channel expects different attributes, different media, different prices. It is not a 1:1 mapping from one record to every channel, and an ERP is not a product database that understands what each channel wants. You can see the ceiling in the vendors' own documentation. Business Central exports item attributes to Shopify "formatted as a table" inside the description field, one authored content set feeding every shop. Sana Commerce, which deliberately keeps product data in the ERP, states it directly: in most cases, ERP systems support only plain text. And Microsoft's own Dynamics 365 documentation lists PIM systems as an expected upstream source of product definitions. The ERP world, in its own words, expects the product record to be authored somewhere else once channels multiply.

Before signing, decide whether product data moves into the new ERP at all. Carving it out into a PIM could shrink the migration itself. We keep seeing the same moment in conversations with operators: the ERP or order-management switch is underway, someone who has been through it warns that the product-configuration side is the painful part, and the scope gets carved live. The new system keeps inventory and orders. The PIM takes listings and product information. What was a full migration becomes a smaller one.

The questions worth answering before the contract is signed:

1. What are your sales channels today, and which ones do you plan to add?
2. How large is the product range, and across how many channels does it need to stay correct?
3. How long does it take you to get a new product live everywhere it sells, and does that speed matter to how you compete?
4. How much do you care about having great product data?

One operator who ran this exercise mid-migration reached his own conclusion, worth quoting because it reframes the whole purchase. He was switching order-and-warehouse tooling for cost and support reasons, and once the PIM owned listings and product information, the tool he was migrating to was just order management to him, and he openly wondered what it was still for. He also said that if he had known the PIM option earlier, he might not have needed that new tool at all. That is his arithmetic about an order-management layer, not a verdict on ERPs or on your stack. But it is cheap to run the same sum before you sign, and expensive to run it after.

One honest caveat: carving product data out is not free readiness. Moving product data and structuring product data are different projects. The carve-out shrinks the ERP migration; the product side still has its own work to do.

Three flows cover most of it. Stock flows from the ERP to your channels. Orders flow from the channels back to the ERP. Product content flows from the PIM to the channels. The two systems are not rivals for the same job; they are neighbours with a shared border.

On that border, the SKU can be born on either side. Usually the ERP masters the SKU: the PIM imports the basic information the ERP knows, and the record gets heavily enriched from there. But the reversed role exists in practice too, where the PIM is the source of new SKUs and the ERP receives them downstream. Either direction works. What stays constant, once a PIM is in place, is the split: the ERP originates the skeleton of a product, and the meaning, the descriptions, attribute values and media that make it sellable, is authored in the PIM.

Day one of connecting the two is less dramatic than it sounds. The PIM reads the SKU list and whatever basics the ERP holds, names, numbers, prices, and pulls them in. From that moment the enrichment work runs on the PIM side: attributes, content, media, channel mapping. The ERP does not change how it works, and the stock and order flows keep running exactly as before.

Pricing follows the same authoring rule. The ERP holds the base price it needs to transact. Selling prices are commercial decisions that vary by channel and by currency, with their own rounding conventions per market, so they are authored where the channels are managed and read back wherever the transaction side needs them. B2B sharpens this further: different customers often get different price lists and different product ranges altogether. An ERP can store the price lists, but organising which customer group sees which slice of the catalogue, with which content and prices, is commercial catalogue work, and it is the kind of separation a PIM keeps clean.

The reads go both ways as well, and this is where a lot of setups leave value behind. A PIM should not own live stock for display; that stays with the ERP. But inventory and sales signals have a legitimate read into the PIM for relational intelligence: related products, substitutions, buy-again logic. Product data informed by commercial reality, without the PIM pretending to be a stock system.

A concrete case: ILFD Group, one of our customers, runs Linnworks for inventory and order management. OneSila did not take anything over from it. What changed was the layer that never existed: an organised way to manage listings, clear workflows, multiple people working on the same products with their own tasks, and visibility on how finished each product actually is and where it is placed. In the team's day-to-day it meant no more clicking through marketplaces to check listings, no spreadsheets, no endless email chains. Coexistence, not replacement, is the common shape.

When catalogue volume times channel count outgrows what the team can keep organised by hand. It is SKU count and channel count, not revenue, and not a single threshold number. You will find plenty of thresholds online and they contradict each other, which tells you what they are worth. The shape matters more than the number: we have seen the need triggered by a catalogue of under 1,000 SKUs, because it was heading for eight sales channels. Channel count alone can carry the argument.

The arithmetic is the tell. A catalogue is not really a count of SKUs; it is SKUs multiplied by the channels each one must stay correct on. A thousand products across eight channels is eight thousand listings that can drift, each with its own attribute expectations. That is rarely something a team keeps organised by hand for long, however good the team.

A useful self-test: how long would it take you to open a new sales channel today? If your product data is structured and in a PIM, the answer tends to be days to weeks. If the data needs work but a foundation exists, months. If neither, probably years. Wherever you land is a reading of your data readiness, and a preview of what every future channel launch will cost you.

Then there is timing, which almost nobody writes about. For most retailers the calendar is binary: a new system either lands before peak-season preparation begins, or it waits for the post-peak window from January to spring. As one operator put it, there is no grey area; a team cannot run a migration and Black Friday prep at the same time, and nobody wants to do configuration work twice. One more piece of honesty belongs next to that: the system and the carve-out can land in weeks, but the shift from channel-first thinking to letting product data flow through one system tends to take longer to settle, often the better part of a year. The calendar gates the launch. The full payoff follows behind it.

Deciding where product data lives before the ERP contract is signed is the cheap version of this decision. Discovering it halfway through the migration is the expensive one. Time to run the sum if you ask me. Your catalogue is not getting smaller.