A Pimcore PIM implementation — from data analysis to launch
We design and implement Pimcore as the central environment for managing product information.
We settle the data model, the roles of the teams, the workflow, the integrations and the rules for publishing to stores, marketplaces and the remaining channels.
- data model
- workflow and permissions
- import and migration
- integration architecture
- QA and documentation
Scattered data starts to limit sales and the team's work
Pimcore starts to make sense once managing product information becomes a separate operational process. The number of records is only one of the factors.
The problem usually appears earlier than the decision to buy a PIM. The team copes with more spreadsheets, more exports and manual checks. Every new market or channel adds exceptions.
- 01
The same product has several versions of its data
The description, the name, the specs or the images differ between the store, the marketplace, the catalogue and a partner's file.
- 02
A new channel means preparing the offer again
The team copies information, changes formats and checks completeness by hand for every recipient.
- 03
Product assets have no single owner
Images, manuals, certificates and translations sit in folders, mailboxes and the systems of different departments.
- 04
Approval happens outside the system
Marketing, sales, the product department and compliance agree changes in messages or in meetings.
- 05
It is hard to tell which version is current
A change in one source gives no certainty that the right information reached every channel.
Installing the system alone will not sort these situations out. The implementation has to settle the data model, the responsibility of each team and the conditions for publication.
See how Pimcore supports e‑commerceBase product
- Variant1:n
- Categoryn:m
- Brandn:1
- Collectionn:m
- Marketn:m
- Language version1:n
- Assets1:n
- Complementary productn:m
Fields of the root object
- code
- name
- description
- technical specs
- relations
The data model in Pimcore — the foundation of a PIM implementation
Pimcore can be configured in many ways. The target structure should follow from the kind of products, the dependencies between them, the data sources and the requirements of the channels.
The model is built before the migration and the integrations, because it defines the target structure of information in the system: the migration maps source data onto that model, and the integrations base their contracts with other systems on it. Changing the model after the environment has been loaded means doing both again.
First we establish which information is to be managed in Pimcore, where it comes from and who may change it. We separate transactional data from descriptive data, define the relations and mark the fields required for individual markets. The model should not copy the current spreadsheet column by column — some of the problems may come from that very structure.
Decisions before development
- 01
Source of truth
We settle which system owns the price, the stock, the code, the description, the image, the translation and the product relations.
- 02
Product structure
We describe base products, variants, sets, categories, collections and the dependencies between records.
- 03
Responsibility
Every field and every stage has an owner. Permissions follow from the user's role and the scope of their work.
- 04
Publication conditions
A product can reach a channel once it meets defined requirements for data, assets and approval.
What the data model defines
- Products
- The base objects: code, name, description, the brand and supplier they belong to.
- Variants
- The axes that split the offer — size, colour, finish — and what a variant inherits from the product.
- Categories
- Trees and taxonomies, including divergent ones: the store's own structure beside the one a marketplace requires.
- Attributes
- Descriptive and commercial fields, their types, value dictionaries and units of measure.
- Relations
- Links between records: bundles, accessories, spare parts, complementary products.
- Technical data
- Parameters, value tables and standards, which become comparisons and filters in the channels.
- Language versions
- Which fields are translated, which are shared across markets and which are local.
- DAM assets
- Images, renders, manuals and certificates linked to the product, the variant and the market.
- Validation
- The rules a field has to satisfy: format, range, whether it is required, whether it depends on another field.
- Data completeness
- The definition of a product ready to publish — set separately for each channel and market.
What a Pimcore implementation covers
The scope is set after the data, the processes and the systems have been analysed. The areas below show the full logic of the project. Not every project needs the same depth.
Analysis of the processes and data sources
We check where information is created today, who fills it in, how it is controlled and where it goes.
The result is a map of sources, recipients, responsibilities and the problems that need solving.
Data model and taxonomy
We design the classes, fields, variants, relations, categories and inheritance rules.
The model accounts for the requirements of individual markets and channels while staying manageable for the team.
Preparing the import and the migration
We define the format of the source data, the field mapping, the handling of gaps and duplicates and the order of the import.
A trial migration comes before the production environment is loaded.
Architecture of the data exchange
We describe which data flows into Pimcore, which is developed inside it and what information reaches the target systems.
For every connection we settle the direction, the range of fields and the moment the data may leave Pimcore.
Workflow, roles and permissions
We define the product statuses, the possible transitions, the owners of each stage and the approval rules.
A user sees the scope matching their role and cannot publish data that fails the agreed conditions.
Asset management
Images, manuals, certificates and other files are linked to the right products, versions and markets.
How far the DAM scope reaches depends on the kind of assets and on how they are distributed afterwards.
Testing, acceptance and launch
We check the model, the permissions, the workflow, the imports and the publication scenarios.
The launch follows once the agreed acceptance criteria are met and a plan for moving to the new way of working is ready.
Analysis of the processes and data sources
We check where information is created today, who fills it in, how it is controlled and where it goes.
The result is a map of sources, recipients, responsibilities and the problems that need solving.
Data model and taxonomy
We design the classes, fields, variants, relations, categories and inheritance rules.
The model accounts for the requirements of individual markets and channels while staying manageable for the team.
Preparing the import and the migration
We define the format of the source data, the field mapping, the handling of gaps and duplicates and the order of the import.
A trial migration comes before the production environment is loaded.
Architecture of the data exchange
We describe which data flows into Pimcore, which is developed inside it and what information reaches the target systems.
For every connection we settle the direction, the range of fields and the moment the data may leave Pimcore.
Workflow, roles and permissions
We define the product statuses, the possible transitions, the owners of each stage and the approval rules.
A user sees the scope matching their role and cannot publish data that fails the agreed conditions.
Asset management
Images, manuals, certificates and other files are linked to the right products, versions and markets.
How far the DAM scope reaches depends on the kind of assets and on how they are distributed afterwards.
Testing, acceptance and launch
We check the model, the permissions, the workflow, the imports and the publication scenarios.
The launch follows once the agreed acceptance criteria are met and a plan for moving to the new way of working is ready.
Building the connections in detail — API, Data Hub, synchronisation schedules and error handling — can be delivered as part of Pimcore integration.
Migrating data into Pimcore
A migration is rarely a matter of rewriting one file into another. Product data is usually scattered across systems and spreadsheets, and its quality only shows once it is mapped onto the target model.
That is why the first import is a trial and runs on a copy of the environment. Its report shows how many records pass without objections, where required fields are missing and which items need a decision on the company's side — only then do we load the production environment.
Supported sources
- XML
- CSV
- Excel
- API
- databases and external systems
What the migration covers
- 01
Data sources
We establish where each kind of information comes from: the ERP, spreadsheets, supplier files, the current store, a catalogue or a previous PIM. For every source we check who maintains it and how often it changes.
- 02
Field mapping
Every source field gets a counterpart in the target model or a transformation rule — splitting a value, changing a unit, assigning it to a dictionary. Fields with no counterpart are a decision, not an omission.
- 03
Cleaning the records
We fix formats, units, character encoding and values written as free text where the model wants a dictionary. Some of those rules stay in the system as validation, so the same errors do not come back after the import.
- 04
Handling duplicates
We agree the key that identifies the same product across several sources, and the merge rule: which source wins on a conflict and what happens to the other values.
- 05
Moving the media
Images, renders, manuals and certificates go into the DAM together with their link to the product, the variant and the market. Files with no link, and those existing in several versions, need a decision of their own before the import.
- 06
Completeness checks
After the import we check the record count, the fields required for each channel and market, and the products that fail validation. The result is a task list for the team rather than a verdict on the migration.
The format of a source is rarely the problem — what decides is the structure and quality of the data inside it. If the migration is to become a regular exchange rather than a one-off load, its scope is described by Pimcore integration.
What does a Pimcore implementation look like, step by step?
Ten stages lead from scattered data to a launch and to further growth. Every one ends with a decision, a document or a working part of the system, so it is clear what has been settled and what is needed to start the next part of the work.
The order of the stages is fixed, but their length depends on the quality of the source data and the availability of the people who make decisions. Where some of the analysis already exists, we start by verifying that material rather than from scratch.
- 01
Analysis of current data and processes
We collect sample data, the list of systems, the publication channels and the user roles. We talk to the people who create, control and use the information.
Resulta map of the current process and a list of problems to solve
- 02
Designing the data model
We describe the objects, fields, variants, categories, relations, language versions, validation rules and the responsibility of each system. This stage also produces the split of scope and the order of delivery.
Resultan accepted data model, a glossary of terms and a backlog
- 03
Configuring Pimcore
We build the classes, the fields, the views for the team and any extensions needed. Each part is presented and verified during the project rather than at the end of it.
Resulta working environment matching the approved model
- 04
Data migration
We map source fields onto the target model, clean the records, handle duplicates and move the media. A trial migration comes before the production environment is loaded.
Resultimported data and a completeness report
- 05
Integrations
We start the data exchange with the source systems and the target channels: the field scope, the direction, the frequency and the error handling are settled for each connection separately.
Resultworking data flows and a description of the contracts
- 06
Configuring workflow and permissions
We define product statuses, the transitions between stages, the owners and what each role can see. A user cannot publish data that does not meet the agreed conditions.
Resultworkflow, roles and publication conditions in the system
- 07
Testing
We check the model, the mappings, the validations, the permissions, the integrations and the users' working scenarios — including the cases where data is incomplete or a source does not answer.
Resulttest results, fixes and readiness for acceptance
- 08
Training the users
The team working with the data learns the admin panel, the workflow, the scope of their own role and how to report problems. The training runs on the target model and on the company's own data.
Resulta trained team and a guide to working in the system
- 09
Launch
We move the agreed production data, switch the target processes on and watch the first cycles of work and of publishing to the channels.
Resulta production environment and an agreed way of working after the start
- 10
Maintenance and further growth
After the start the system needs request handling, updates, integration monitoring and growth of the model, the workflow and the exports as the offer changes.
Resultan agreed maintenance scope and a growth backlog
Every system needs a clearly defined role
The ERP can stay the source of codes, prices or stock. Pimcore takes over the data that needs developing, organising, approving and distributing. The store and the remaining channels receive information prepared for their specific needs.
The split depends on the existing architecture. In one project Pimcore manages mainly product information and assets. In another it also covers master data on brands, suppliers, categories or other objects.
Source systems
- ERP
- Warehouse system
- Supplier files
- Internal teams
Pimcore
Channels and recipients
- Magento 2
- Shopify
- Marketplace
- B2B portal
- Catalogue
- Apps
What passes through each layer
- The source systems hand over codes, supplier data and operational information, and prices and stock where that split is agreed.
- Pimcore organises the structures and relations, the content and translations, the assets, the completeness and the approval statuses.
- The channels receive the required set of fields in the right language, the matching assets and data that meets the publication conditions.
- The diagram shows the roles systems can take. Not every project contains all of the elements listed.
Pimcore brings PIM, MDM, DAM, DXP and commerce together — the platform documentation covers them (opens in a new tab) — but an implementation should only include the parts justified by the company's processes.
How much does a Pimcore implementation cost, and how long does it take?
We publish neither one price nor one duration for every Pimcore project — an implementation for one catalogue and one channel is different work from a model serving several brands, markets and systems. Below are the eight things that move the estimate and the schedule most.
What moves the estimate and the schedule
- The number of records
- It affects the design of the model less and the migration, the performance and the time a catalogue change takes to propagate more. A few million variants also change how the team works in the panel.
- The complexity of the data model
- The number of classes, fields, levels of inheritance and relations between objects. A catalogue where a product is made of parts and variants along several axes takes longer to analyse than a flat list.
- Migration
- The number of sources and the state of the data in each. Cleaning, merging duplicates and filling gaps is often a larger part of the project than configuring the system.
- Workflow
- How many stages a product goes through, what the transitions require, and whether publishing should be blocked while data is incomplete.
- The number of users
- The more people and departments work with the data, the more roles, permissions and views there are to design — and the longer the training and acceptance take.
- Integrations
- The number of systems, the directions of exchange, the frequency and the quality of the data on the other side. Every flow needs error handling and reprocessing.
- The number of target channels
- Every channel takes a different set of fields, in a different format and with its own definition of completeness. The second channel costs less than the first, but it is not free.
- Custom development
- Anywhere from a configuration on standard mechanisms to custom views, validation, automation and exports built for one specific recipient.
The estimate and the schedule are produced after the data, the sources and the channels have been analysed — that is, after the first two stages of the process above, when it is clear what is configuration and what is development. An implementation can be split into stages: the first usually covers one set of data and one channel, and the next ones add more. The cost of the work after go-live is described by Pimcore maintenance.
Pimcore will not pay off in every project
The system needs its model designed and the way of working with data changed. With a small number of products, one channel and a simple process, the cost of an implementation can outweigh the benefits.
In the first conversation we separate the need for a new implementation from an integration or a maintenance problem. A company should not start a larger project when a smaller scope is enough.
FAQ — a Pimcore implementation
The questions cover cost, timeline, analysis, data migration, training, the edition of the system and taking over a project already under way.
Let's discuss a Pimcore implementationIt covers designing the data model, the roles, the workflow and the way information is imported and distributed. Configuring the system and development start once those decisions are made.
Most often when a company manages a large or complex offer, several languages, markets or channels. The number of people involved in preparing and approving the data matters just as much. We compare this class of solution in an article on PIM systems in e‑commerce (opens in a new tab).
Yes. The scope can cover product data, other master data, relations between objects and digital assets. Whether PIM, MDM or DAM is used follows from the needs of the project — the platform develops those areas together (opens in a new tab).
Yes, and it is one of the typical elements of a PIM architecture. First we settle the responsibility of each system and the directions of the data flow — the ERP usually stays the source of codes, prices and stock, while Pimcore takes over descriptions, attributes, relations and assets. Then we design the imports, the exports or the API integrations; the details of the connections are covered by Pimcore integration.
Product data, categories, attributes, relations, translations and digital assets — from spreadsheets, supplier files, the current store, an ERP or a previous PIM. The source can be XML, CSV, Excel, an API, or databases and external systems; the format itself is rarely the problem, what decides is the structure and quality of the data inside. The work is described in the section on data migration.
Yes, and it is the first stage of the process rather than an add-on to it. Without checking where the data is created, who fills it in and what each channel requires, the model would be built on guesswork and the migration would only reveal that at import time. If a company already has its own analysis, we start by verifying it rather than from scratch.
Yes, and that is usually how we run it. The first stage typically covers one set of data and one channel — the model, the migration and the publishing taken all the way through — and the next ones add further channels, markets or areas such as DAM or master data. What it takes is a model that allows for those extensions from the start.
Yes, training the users is a stage of its own before the launch. It runs on the target model and on the company's own data rather than on a sample catalogue, and covers the admin panel, the workflow, the scope of each role and how to report problems. The team also receives a guide to working in the system.
No. Pimcore stands beside the sales platform and feeds it data — the store still handles the cart, payments and orders. What changes is where its descriptions, attributes and assets come from: they stop being entered in the store itself. Replacing the platform is a separate decision and a separate project.
That is one of the main reasons companies reach for a PIM. The model settles which fields are translated, which are shared across markets and which are local, plus a separate definition of completeness per market — a product ready to publish in Poland need not be ready in Germany. Translations and statuses are visible in one place instead of in a spreadsheet per market.
We do not publish one price for every project. The estimate is driven by the number of records, the complexity of the data model, the scope of migration, the workflow, the number of users, the integrations, the number of target channels and the scope of custom development — all eight are set out in the section on cost and time.
We do not give a date before the analysis. The timeline follows from the data model, the number of integrations, the quality of the sources, the scope of the workflow and the availability of the people who decide — we prepare a schedule after the first two stages of the process, once the analysis is done and the model approved. Staging the work makes it possible to launch the first channel without waiting for the full scope.
Pimcore runs on an open-core model and has several editions. The choice depends among other things on the organisation's licensing terms, the modules needed and how the system will be maintained. We verify the current terms before preparing an offer — the editions are compared in the documentation (opens in a new tab).
After the start the system needs bug handling, updates, integration monitoring and further development. That scope can be taken over as Pimcore maintenance.
First we review the code, the configuration, the data model, the integrations and the state of the documentation. After that audit we can say which parts can be continued and which need fixing or redesigning.
Let's start from the data and the systems that already work
You do not need a finished specification. Describe the data sources, the channels and the place where the current process starts to block. In the first conversation we will establish whether a new implementation, an integration or work on an existing Pimcore is what you need.
Worth having for the first call
- a rough number of products or records
- the list of systems the data comes from
- the number of markets and sales channels
- who is responsible for the product data
- the stage the project is at