Pimcore development and integration, Austria and Germany

A Pimcore data model is a set of decisions about where each attribute lives, and those decisions age. Plain class fields are fast to query and simple to reason about, but every product carries them whether or not they apply. Object bricks attach an optional block of developer-defined fields to some objects. Classification store holds attributes as grouped key-value data, editable by data managers without a deploy.

The failure that produces a slow, awkward instance is almost never a wrong choice at the start. It is that nobody re-examined the choice when the catalogue changed. A class that made sense with two product families is a wall of mostly-empty fields with eleven. That is the work: deciding what should move, and moving it without breaking the integrations that read it.

• Class, brick, field collection, and classification store structure, and which attribute belongs in which
• Localization: which fields are localized, which markets share a language, and where fallbacks apply
• Relations and dependencies, including the ones that make listings slow at volume
• Variant and inheritance structure for catalogues where products differ by a handful of attributes

Pimcore sits in the middle: the ERP is usually upstream and the source of record for commercial data, the shop and channels are downstream, and the DAM and translation systems sit alongside. Pimcore data integration work is mostly about deciding which system owns which field and then defending that decision in code.

For reads, the Data Hub GraphQL endpoint usually beats hand-rolled REST, because a consumer asks for exactly the fields it needs and a new attribute stays invisible until the endpoint config exposes it. For writes, imports should be idempotent and keyed on an external identifier, so the same file processed twice does not produce duplicates. Errors need somewhere to surface that a person actually looks at.

• Scheduled ERP imports, staged and validated before they touch live objects
• Data Hub GraphQL and REST endpoints for shops, channels, and internal consumers
• DAM synchronisation so products reference the approved asset rather than a copy
• Translation round trips into localized fields without overwriting newer edits

Pimcore does all three, and treating that as one decision is where projects go wrong. As a PIM it is strong: structured product data, variants, inheritance, and multi-market localization are what the data object model is built for.

As a DAM it is capable but not always the right answer. If your asset workflow involves rights management, review chains, and large volumes of raw media, a dedicated DAM alongside Pimcore is often the better arrangement, which is exactly how the medical device manufacturer in our case study ran it. As a CMS it works well when the site is essentially a view onto the product data, and less well when the marketing site has a life of its own.

• Small, roughly one to two weeks: a single integration, a data model repair scoped to one class, a performance fix on a slow listing or export, an upgrade across minor versions
• Medium, roughly three to six weeks: a data model restructure with the migration to go with it, a new channel or shop integration end to end, a major version upgrade on an instance that is one or two versions behind
• Large, a quarter or more: a catalogue migration from spreadsheets or a legacy PIM, a multi-market localization rollout, or a major upgrade on an instance that has skipped several versions and accumulated custom code
• Ongoing: the monthly retainer, where the work is a steady stream of small changes plus a planned upgrade path rather than a project

This is the common case and the thing we are set up for. Somebody else implemented your Pimcore, the people who built it have moved on, and what you need is someone who can read an unfamiliar system quickly and be honest about its state.

That starts with the health check: one week, a fixed €2,500, a written report on version exposure, data model, integrations, performance, and security, with a prioritised fix list against it. After that either you have what you need to brief somebody else, or we work through the list.

If your catalogue is a few hundred products with a stable attribute set and one sales channel, Pimcore is more platform than the problem needs, and a focused custom build will be cheaper to run and easier to change.

If you are choosing between Pimcore, Akeneo, and building something, that is a selection question rather than a development one. We have written about the comparison, and we will say plainly when the answer is not the system we specialise in.