The first question anyone technical asks is which system is master of what. The answer is narrower than it sounds.
Ownership, plainly
| Master | |
|---|---|
| Stock, cost, lead time | your ERP |
| Orders, invoices, production | your ERP |
| Customer accounts, checkout | your shop |
| Product attributes, translations | your PIM, if you have one |
| Which options are valid together | the catalogue layer |
| What each combination looks like | the catalogue layer |
| What the buyer sees on the page | the catalogue layer |
Nothing moves out of the ERP. The catalogue layer reads what it needs and owns only the thing no other system claims: the visual and configurable truth of the product.
Why that boundary and not another
Because it is the one nobody else wants. Ask an ERP what a sofa looks like in grey linen and it has no opinion. Ask a shop platform whether a corner module can take an armrest on the left and it has no idea. Those questions have to live somewhere, and today they usually live in a person’s head.
What this means for a migration
You are not replacing anything. You are adding the layer that currently exists as tribal knowledge and a folder of renders, which is why these projects tend to be additive rather than a rip-out, and why they can start on one product range.
