Pimcore and Adobe Commerce integration: delivery lessons from a five-brand programme
Connecting a PIM to a commerce platform looks like a technical integration. In practice it is a data-ownership project. On a five-brand industrial-tools programme, making Pimcore the single source of truth for product data and feeding it to Adobe Commerce went well because the business decisions were made before the code was written.
Decide who owns each piece of data
Before any mapping, agree which system owns which data. In our case Pimcore owned product content: names, descriptions, technical attributes, media references and category assignment. The ERP owned price and stock. Adobe Commerce owned what only a storefront needs: URL keys, merchandising, promotions and customer-facing configuration. Writing this down in one page prevented weeks of arguments later.
The rule that saved us most often: a field has exactly one owner. If content editors can change a product name in both Pimcore and Magento, the next sync will overwrite someone's work and trust in the PIM disappears.
Attribute mapping is where the effort really goes
Five brands meant five slightly different ways of describing similar products. Harmonising attribute sets, units, option values and category trees took more time than the connector itself. We built a mapping workbook with the client's product team: Pimcore attribute, Magento attribute code, type, scope (global, website or store view), transformation rule and owner. Every row was signed off by the business before development started.
Design the sync for failure, not for the happy path
- Prefer incremental, event-driven updates over nightly full imports once the catalogue is stable.
- Keep a full re-sync available for recovery, and test it.
- Validate in Pimcore before export: a product missing required attributes should never reach the storefront.
- Log every failed item with a reason the product team can read, not only a stack trace.
- Handle media separately; large image sets slow everything else down.
Test with real catalogue data early
Sample data hides problems. We moved to a copy of the real catalogue as soon as the first connector worked, and the product team reviewed a set of known difficult products (configurables with many options, bundles, products with long technical tables) on the storefront in every sprint. Most of the issues found were data issues, not code issues, and fixing them early is far cheaper than during UAT.
Roll out brand by brand
We did not switch five brands at once. Each brand moved to PIM-driven content in turn, with a period where the product team worked only in Pimcore and verified the storefront, before the next brand began. That kept four storefronts trading normally while one was changing, and every rollout was faster than the last.
The integration later made it straightforward to add a digital asset management system and a generative-AI content feature inside Pimcore, because the data model and the ownership rules were already clear.
Frequently asked questions
- What does a Pimcore to Adobe Commerce integration do?
- It makes Pimcore the source of truth for product content, such as attributes, descriptions, media and categories, and synchronises that content to Adobe Commerce (Magento) storefronts, while price and stock usually come from the ERP.
- What is the hardest part of a PIM integration?
- Data ownership and attribute mapping. Agreeing which system owns each field, and harmonising attribute sets, units and categories across brands, takes more effort than building the connector.
- Should you migrate all brands to a PIM at once?
- Usually not. Rolling out brand by brand keeps the other storefronts trading normally, lets the product team learn the new workflow, and makes each later rollout faster.
If you are building or fixing a delivery organisation and want someone who has run one as a business, book 20 minutes.
Book a 20-minute intro call