Someone in the room says the product images should live in the PIM, because images belong to products. Someone else says they should live in the DAM, because that is what a DAM is for. Both people are describing the same photograph and both are partly right, which is why the meeting runs long and ends with a decision to “sync them”.
That decision is the expensive one.
Short answer: a DAM owns the asset and everything intrinsic to it. A PIM owns the product record and everything intrinsic to that. The image file, its rights, its version history and what it depicts belong to the DAM. The statement “these six images depict SKU 44-2210” belongs to the PIM, because it is a fact about the product, not about the photograph. Get that one line right and most boundary arguments answer themselves.
What each system is actually holding
Strip out the feature overlap that every vendor adds to compete with the other category, and two very different shapes remain.
A digital asset management system holds files that are expensive to produce and reused in many places. Its record is the asset. It cares about the master file, the renditions derived from it, who shot it, what licence attaches, when that licence expires, which version is current, and what the image shows. Its hard problems are storage, search, rights and delivery. There is more on the shape of that record in what a DAM actually does.
A product information management system holds structured facts about things you sell. Its record is the product. It cares about identifiers, attributes, variants, category placement, per-market copy and completeness against a channel’s requirements. Its hard problems are schema, validation, localisation and syndication. What a PIM actually does covers that side.
The overlap is small and it is always the same three things: the association between products and images, alt text, and crops.
The authority rule
Write this into the architecture decision record before anyone opens a vendor site:
For every field, exactly one system is authoritative. Every other system that displays that field holds a reference, not a copy. If a second system must store the value for performance, it stores it as a cache with a defined refresh, and it is never edited there.
The failure this prevents is the only one that really hurts: two systems that both allow editing of the same field. That produces divergence, and divergence in a field like licence expiry or net weight is not untidiness. It is a defect with a legal or commercial consequence.
The corollary matters as much as the rule. “We will sync it both ways” is nearly always the wrong answer, because bidirectional sync between two editable systems is a conflict resolution problem, and conflict resolution gets designed at the end of the project by whoever is left.
The field-by-field map
This is not universal, but every exception should be deliberate and written down.
The DAM owns: the master file and its renditions, what the asset depicts, creator and shoot date, licence terms and expiry, model and property releases, approval state, colour profile, asset version history, and a default description of the image.
The PIM owns: product identifiers including SKU and GTIN, attributes and specifications, variant structure, category placement in the commerce sense, per-market marketing copy, pricing structure, channel completeness rules, and the association between a product and its assets.
Nobody owns anything twice. The association is the case people get backwards most often. It belongs in the PIM. The DAM holds the photograph; the PIM holds the sentence “this photograph shows this SKU”. Put that association in the DAM and you have quietly built a second product catalogue inside your asset library, with none of the validation and none of the channel rules.
The same reasoning extends to the CMS and the ERP, which have their own claims on some of these fields. The boundary map works through all four.
The three genuine arguments
Most of the map is uncontroversial once it is written down. Three areas are not.
Alt text. The DAM has the better claim, because the text describes the image and the image is reusable. The CMS and PIM have a real counter-argument, because good alt text is contextual and the same photograph legitimately needs different text on a category tile and in a size guide. The workable answer is two fields rather than one fight: the DAM holds a default description of what is depicted, and the surface that places the image may override it. MDN’s guidance on the img element supports that reading, since alt text serves the function of the image in its context and the context is not known at asset level.
Crops and renditions. Historically both systems stored their own files, produced by someone, kept somewhere, going stale independently. The clean answer removes the argument rather than settling it: neither system stores a crop, and both request one by parameter at the point of use. When a rendition is derived rather than stored, there is no artefact to own. Platforms built around URL-level transformation, Cloudinary being the most complete example, turn this governance dispute into a query string.
Enrichment copy. Marketing copy about a product goes in the PIM. Copy about an asset, such as a caption or a credit line, goes in the DAM. The grey area is the campaign description that mentions both, and the honest answer is that it usually belongs in whichever system the people writing it already work in.
Do you need both?
Often not, and this is the question the comparison pages never ask.
- Under a few hundred SKUs, one market, one channel: your storefront platform’s own product fields and media library are genuinely enough. Adding either system adds an integration without adding an answer. Do you need a PIM yet sets out the thresholds.
- Many SKUs, few images: you need a PIM and probably not a DAM. Industrial and component catalogues live here. The images are line drawings and spec sheets, and the storefront can hold them.
- Few SKUs, many images: you need a DAM and probably not a PIM. Fashion, furniture and anything shot repeatedly per season sits here. Twelve hundred photographs of forty products is an asset problem wearing a product costume.
- Both, at volume, across markets: you need both, and you need the boundary written down before either is bought.
What you should not do is buy one system to fix a problem the other one owns. A DAM bought to clean up product data will not clean up product data, and a PIM bought to manage images will manage them badly, in a schema designed for attributes. The cost comparison shows what that mistake looks like on an invoice.
How do you decide when both systems offer the same feature?
Three questions, in order. They resolve almost everything.
- Which system holds the record this field describes? Licence expiry describes an image, and the image is in the DAM. Net weight describes a product, and the product is in the PIM. Most fields stop here.
- Which system’s users maintain it? If photographers and cataloguers maintain a field and they work in the DAM, putting the field in the PIM guarantees it stays empty. Authority should follow the workflow wherever the first question leaves room.
- Which system can enforce it? A field with a controlled vocabulary and validation in one system and free text in the other is not really a choice. Enforcement wins, because an unenforced field becomes an inconsistent field, and an inconsistent field becomes a field nobody trusts.
Write the answers into an ownership matrix, get it signed by whoever owns each system, and keep it where the integration team can find it. That single artefact prevents more rework than any other document in the project, and it is the input to single source of truth applied to product data, which is where the rule gets tested against real fields.