We establish where the data is today, who creates it and which systems need it.
PIM for e-commerce
The problem usually does not start with a company "needing Pimcore".
It starts when product data is scattered across ERP, Magento, spreadsheets and other systems, and it becomes increasingly difficult to answer a simple question: which version of the information is correct, and who is responsible for it?
We design product data architectures and implement PIM solutions. First, we identify data sources, assign data ownership and define the target information model. Only then do we choose the technology.
If PIM is unnecessary or a simpler solution will suffice, we will tell you.
A free 30–60 minute call. We will learn about your product data sources, current processes and publication channels. We will provide an initial assessment of whether a PIM addresses the key problems and which areas require analysis.
The challenge
When the catalogue is no longer the only problem
At first, the way products are managed is often simple.
ERP supplies the basic information. Marketing adds descriptions in Magento. Images live in a separate directory. Translations are prepared in spreadsheets.
With one market and a small catalogue, this model can work for years.
The problem appears when more languages, markets, variants, attributes and publishing channels are added. The same information begins to exist in several places, and changing a product requires several people to work in different tools.
At that point, the problem is no longer a missing field in Magento.
The problem is the lack of a coherent model for managing product information.
Data ownership
PIM starts with responsibility for data
Implementing another system will not solve the problem if the same information can still be changed independently in several places.
That is why one of the first questions is: which system is responsible for each piece of information?
For example, ERP may be the source of SKUs, prices, stock levels and commercial information; PIM may own descriptions, attributes, relationships, translations and marketing content; DAM may own images and documents; and Magento may handle product presentation and the sales process.
That is only an example. In a particular project, the boundaries may be different, often at the level of individual fields rather than entire systems.
The test is simple. If a product description can still be corrected in three places after implementation and no one can say which one is authoritative, PIM has not changed the way the team works. It has merely been added to the existing setup.
Information model
Data model before choosing technology
PIM should not be a place where an existing structure is moved simply because it was created at some point in the past.
For large and complex catalogues, we analyse products and variants, attributes, relationships between products, classifications, language versions, differences between markets and how content is published to individual channels.
If the existing model has accumulated duplicates and exceptions over the years, implementing PIM is a good opportunity to simplify it.
Moving the mess from Excel or Magento to a new platform only preserves the problem in a more expensive tool.
Multiple markets
Multiple markets mean more than translations
The same product may need a different name, description, set of documents or required information depending on the market.
There are also marketplaces, feeds, B2B catalogues, apps and other channels.
PIM makes it possible to separate shared product data from market-specific information and content prepared for a particular channel.
As a result, entering a new market does not have to mean creating another independent version of the catalogue.
Product workflow
Workflow: a product has a process, not just a set of fields
In a larger organisation, product data is rarely prepared by one person.
The product team provides technical data. Marketing writes descriptions. Someone prepares translations. Another person manages images and documents. A product may need approval before publication.
PIM can support this process as a workflow.
We can design:
- roles and stages of product preparation,
- fields required at each stage,
- approvals and data-readiness statuses,
- rules for publishing to channels.
This means the organisation does not have to rely on the memory of people working on the catalogue or additional tracking spreadsheets.
Digital assets
DAM and media
In many projects, the product data problem extends beyond text and attributes. Images, manuals, certificates, technical documentation and marketing materials also need to be managed.
Pimcore can combine PIM and DAM functions, linking assets to products, language versions and markets.
Not every project needs this. DAM belongs in the architecture when it genuinely solves a problem with organising materials.
Choosing a solution
Pimcore or another solution?
We do not start a project by deciding: "we are implementing Pimcore".
First, we examine the data structure, the number of markets and channels, how the team works, workflow needs, DAM requirements and integrations with ERP and e-commerce.
Pimcore works well in projects that need a flexible data model, relationships between objects and an extensive DAM layer.
If the requirements are simpler or a more specialised PIM is a better fit, we will say so - even if it means a smaller project for us.
Technology should follow the process and information model, not the other way around.
Integrations
PIM must work with ERP and Magento
PIM should not become another independent island.
A typical flow might look like this:
ERP → core data → PIM → enrichment and organisation → Magento and other channels
But some information may just as well originate directly in PIM, with ERP receiving only selected data.
During discovery, we define information sources, flow directions, system responsibilities, synchronisation frequency and data mapping. Only then do we build the integration.
Project experience
Experience with complex data
In one large migration project, we worked with a database containing hundreds of thousands of products and years of legacy data.
An important part of the work was not simply moving records, but organising them: removing inactive items, normalising inconsistencies, mapping to a new model and reconciling the new platform's requirements with the existing ERP and SEO structure.
It was not a PIM project.
It does, however, show the kind of problem PIM is often expected to address later: at scale, manually correcting data stops being a process on which e-commerce growth can rely.
How we work
How we run a PIM project
-
01
Data landscape analysis
-
02
Data ownership
We define the source of truth for each type of data.
-
03
Data model
We design products, attributes, relationships, language versions, markets and publishing rules.
-
04
Platform selection
Only at this stage do we recommend Pimcore or another PIM solution.
-
05
Integration architecture
We design data exchange with ERP, Magento, DAM and the remaining channels.
-
06
Implementation
We build the data model, workflow, roles and necessary extensions.
-
07
Data migration
We map, clean and migrate data to the new structure.
-
08
End-to-end testing
We test the entire flow - from the source system to the final publishing channel.
Assessing the need
When PIM may be unnecessary
PIM is not a mandatory part of mature e-commerce.
If the catalogue is simple, the company operates in one market, the data is consistent and ERP and Magento have clearly defined roles, adding another platform may only increase maintenance costs.
In that case, it is better to organise the existing architecture than to justify implementing an additional system.
Experience
Why Velocity
We see PIM as part of the overall e-commerce architecture.
We work with Magento, large catalogues, ERP integrations, search and data migrations. That is why, for us, a PIM project does not end with configuring a dashboard.
We are interested in the entire flow:
ERP → PIM → Magento → search → other channels.
If the problem can be solved without PIM, we will not make a case for another platform.
Fit
When the problem lies elsewhere
ERP integrations
If the main problem is prices, stock, orders and communication between Magento and the operational system, ERP integrations are the right starting point.
ERP integrations →Large catalogues in Magento
If the data is well organised but catalogue scale is beginning to affect Magento performance, large catalogues require a dedicated approach.
Large catalogues in Magento →Performance and security audit
If you are unsure where the bottleneck lies, a free performance and security audit can be the starting point.
Migration and replatforming
If the challenge is moving the entire current platform and its data to Magento, migration and replatforming are the right direction.
Migration and replatforming →Questions
FAQ
VLCT
PIM is a system for managing product information: attributes, descriptions, relationships, translations and versions of data intended for different channels.
VLCT
Usually not. ERP can continue to manage prices, stock and commercial information, while PIM manages descriptive and product data.
VLCT
No. Magento handles commerce and the sales process. PIM prepares and distributes the data used by Magento.
VLCT
Pimcore is particularly interesting when the data model is complex, there are many relationships, DAM requirements and a need to build flexible processes.
VLCT
Pimcore is the solution we know best. If discovery shows that a tool focused solely on managing and enriching product data, such as Akeneo, would be a better fit, we will say so and support its implementation.
VLCT
Not always, but multiple languages and markets significantly increase the value of centralised product information management.
VLCT
Yes. With Pimcore, asset management can be part of the same solution.
VLCT
We assess this need during discovery. In practice, implementing PIM is often a good time to organise the model and resolve historical inconsistencies.
VLCT
Yes. If the problem can be solved with a simpler change to the data model or integration, that is a better recommendation than implementing another system.