Core · Gids
Van het ene PIM naar het andere migreren zonder dataverlies (2026)
Laatst bijgewerkt: 7 november 2026.
Je migreert zonder dataverlies van het ene PIM naar het andere door de bron te inventariseren en te bevriezen, het oude datamodel attribuut voor attribuut op het nieuwe te mappen en minstens één volledige proefmigratie te draaien vóór de echte migratie. Na elke proefmigratie reconcilieer je aantallen en waarden per attribuut tegen de bevroren baseline, en je houdt het oude PIM read-only tot het nieuwe foutloos naar elk kanaal heeft gepubliceerd. Bij een catalogus met veel varianten, talen of relaties zijn twee of drie proefmigraties veiliger dan één.
Deze gids is voor teams die al een PIM gebruiken en overstappen naar een ander: van Akeneo naar Pimcore, van Salsify naar inriver, van een eigen PIM naar SaaS, of welk ander paar dan ook. Je leest wat er meestal kwijtraakt, hoe je inventariseert en mapt, welke overstapaanpak je kiest, hoe je bewijst dat er niets ontbreekt en wat de grote platforms documenteren over het exporteren van je data. Is dit je eerste PIM, begin dan met de gids voor PIM-implementatie, want een eerste implementatie start vanuit spreadsheets en een ERP, niet vanuit een ander datamodel.
Wat raakt er kwijt bij een PIM-migratie, en waarom?
Een PIM-naar-PIM-migratie is een vertaling tussen twee datamodellen. De productregels komen meestal wel aan. Wat ontbreekt, is de structuur eromheen, omdat geen twee PIM's die op dezelfde manier modelleren. Onze gids over het productdatamodel legt de bouwstenen uit; dit zijn de bouwstenen die breken.
| Wat raakt kwijt | Hoe het gebeurt | Wat je controleert |
|---|---|---|
| Attributen | Een veld heeft geen doel in het nieuwe model, of twee oude velden worden zonder regel samengevoegd | Elk bronattribuut heeft een gemapt doel, een expliciete "drop" of een archiefbesluit |
| Optielijsten en eenheden | Codes worden labels, labels veranderen, eenheden staan door elkaar in één veld | Toegestane waarden en eenheden kloppen per attribuut na de load |
| Varianten | Variantstructuren met meerdere niveaus worden platgeslagen, of de as die een variant definieert gaat verloren | Aantallen parents en children, variantassen en overgeërfde waarden per familie |
| Relaties | Associaties, cross-sells, accessoires, bundels en onderdeelkoppelingen verwijzen naar identifiers die zijn veranderd | Aantal relaties per type, en geen relatie die naar een ontbrekend product verwijst |
| Assets en hun koppelingen | Bestanden verhuizen, maar de koppeling met het product, de rol (hoofdafbeelding, datasheet) of de volgorde gaat verloren | Aantal assets per product, assetrol, sorteervolgorde en bestanden die openen |
| Vertalingen | Locales die maar deels gevuld zijn worden overgeslagen, of fallbackregels verschillen | Vulgraad per attribuut per locale, voor en na |
| Kanaalregels | Volledigheidsregels, kanaalspecifieke waarden en exportmappings zitten in de configuratie van het oude PIM, niet in de data | Een geschreven lijst met regels per kanaal, opnieuw gebouwd en getest in het nieuwe PIM |
| Workflowstatussen | "In review" of "goedgekeurd" heeft geen equivalent, dus producten komen binnen met de verkeerde status | Status per product, en openstaande taken bewust opnieuw gestart |
| Geschiedenis | Versiegeschiedenis en auditlogs zijn zelden exporteerbaar in een vorm die het nieuwe PIM kan laden | Een gearchiveerde, leesbare kopie die je bewaart voor audits |
Achter de meeste van deze regels zitten twee oorzaken. Ten eerste veranderen de identifiers: als het nieuwe PIM zijn eigen interne ID's aanmaakt, moet elke relatie, assetkoppeling en integratie die naar het oude ID verwees opnieuw worden gemapt. Spreek één stabiele zakelijke identifier af, zoals de SKU of een GTIN, die in beide systemen bestaat en waarop elke lookup draait. Ten tweede is configuratie geen data. Volledigheidsregels, kanaalmappings en workflowdefinities zijn vaak het resultaat van jaren kleine beslissingen, en die komen niet mee in een export.
Wat moet je inventariseren voordat je iets verplaatst?
Begin met een lijst van alles wat het oude PIM bevat, wie de eigenaar is en of het meegaat. Maak daarna een baseline-export en bevries die: een read-only kopie van de bron op een bekend moment. Elke latere check vergelijkt met die baseline, dus die mag niet veranderen.
| Data-object | Waar het meestal staat | Eigenaar | Migreren? |
|---|---|---|---|
| Producten en SKU's | PIM-kern | Productdatateam | Ja, actieve producten; beslis over uitgefaseerde producten |
| Productmodellen, families en variantstructuren | PIM-datamodel | PIM-beheerder | Ja, opnieuw gemodelleerd voor het doelsysteem |
| Attributen, optielijsten en eenheden | PIM-datamodel | PIM-beheerder met categorie-eigenaren | Ja, na profilering |
| Categorieën en kanaaltaxonomieën | PIM, soms het commerceplatform | Categorie- of e-commercemanager | Ja, eigen boom; kanaalmappings opnieuw bouwen |
| Relaties, bundels en onderdeelkoppelingen | PIM-relaties | Categorie-eigenaren | Ja |
| Assets en hun metadata | PIM, ingebouwde DAM of een aparte DAM | Marketing- of contentteam | Ja, met koppelingen en rollen |
| Vertalingen per locale | PIM-waarden | Eigenaar lokalisatie | Ja, met vulgraden eerst gemeten |
| Leveranciersdata en onboardingmappings | PIM of leveranciersportaal | Inkoop of team data-onboarding | Mappings: opnieuw bouwen; ruwe bestanden: archiveren |
| Volledigheids- en validatieregels | PIM-configuratie | PIM-beheerder | Opnieuw bouwen en testen; in de meeste PIM's niet als data te exporteren |
| Kanaalexports, feeds en connectoren | PIM-configuratie of integratielaag | E-commerce en IT | Per kanaal opnieuw bouwen |
| Workflowstatussen en openstaande taken | PIM-workflow | Data stewards | Opnieuw starten in het nieuwe PIM |
| Versiegeschiedenis en auditlog | PIM | Compliance of IT | Archiveren, zelden migreren |
| Gebruikers, rollen en rechten | PIM-beheer | PIM-beheerder | Opnieuw aanmaken, niet blind kopiëren |
Uitgefaseerde producten verdienen een eigen besluit. Migreer ze alleen als een proces ze in het PIM nodig heeft, zoals het opzoeken van onderdelen, garantie of een B2B-portal die ze nog toont. Al het andere kan naar een archief dat iemand kan lezen zonder het oude systeem.
Profileer voordat je mapt
Meet de bron voordat je de mapping ontwerpt. Per attribuut: hoe vaak het gevuld is, welke formaten en eenheden voorkomen, hoeveel dubbele records en verweesde relaties er zijn en hoe volledig elke locale is. Een veld dat in een grote catalogus maar voor een handvol producten gevuld is, vraagt om een besluit, niet om een mapping. Profilering maakt van de vraag "opschonen voor of na" hieronder een lijst met namen erbij.
Hoe map je het oude datamodel op het nieuwe?
Leg de mapping vast, attribuut voor attribuut, en geef elke regel een eigenaar. Een spreadsheet is prima, zolang die deze kolommen heeft:
| Kolom | Wat erin staat |
|---|---|
| Bronobject en -attribuut | De code in het oude PIM, niet het label |
| Doelobject en -attribuut | De code in het nieuwe PIM, of "drop" of "archief" |
| Transformatieregel | Eenheidsconversie, splitsen, samenvoegen, code naar optie, tekst naar getal |
| Locale- en kanaalscope | Of de waarde per locale, per kanaal of globaal is, in beide systemen |
| Standaardwaarde of fallback | Wat er gebeurt als de bron leeg is |
| Eigenaar | De persoon uit de business die bepaalt wat het veld betekent |
| Testgeval | Eén echt product dat bewijst dat de regel werkt |
Map de structuur vóór de waarden. Beslis eerst hoe het nieuwe PIM families, variantniveaus, relaties en assetrollen weergeeft, want die beslissingen veranderen de vorm van elk product. Map daarna de attributen binnen die structuur. Gebruik aan beide kanten codes, geen labels: labels veranderen met taal en bewerkingen, codes blijven stabiel.
Drie mappingbeslissingen veroorzaken later het meeste herstelwerk:
- Variantniveaus. Heeft het oude PIM twee variantniveaus (bijvoorbeeld model, kleur, maat) en modelleert het nieuwe varianten anders, beslis dan vóór de eerste load waar elk attribuut komt te staan, want waarden later tussen niveaus verschuiven betekent opnieuw laden.
- Scope. Een attribuut dat in het ene systeem per kanaal is en in het andere globaal, dwingt een keuze af: één waarde houden, of kanaalspecifieke attributen aanmaken. Maak die keuze expliciet.
- Relaties. Laad parents vóór afhankelijke objecten: referentiedata, dan categorieën, dan producten, dan relaties en assets. Een relatie die verwijst naar een product dat nog niet geladen is, faalt in veel importers zonder foutmelding.
Opschonen voor of na de verhuizing?
Allebei, verdeeld per type probleem. Zo blijft de migratie eindig en het nieuwe PIM schoon.
| Type probleem | Wanneer je het oplost | Waarom |
|---|---|---|
| Dubbele records, ongeldige identifiers, uitgefaseerde producten | Vóór de extractie, in de bron | Ze vermenigvuldigen zich in elke volgende stap en breken relaties |
| Gemengde eenheden, vrije tekst die een optielijst hoort te zijn, inconsistente formaten | Tijdens de migratie, met geschreven transformatieregels | De regel documenteert het besluit en werkt in elke proefmigratie op dezelfde manier |
| Ontbrekende verrijking: nieuwe attributen, betere omschrijvingen, extra afbeeldingen | Na de go-live, in het nieuwe PIM | Het is nieuw werk, geen migratie, en het zou de overstapdatum steeds laten opschuiven |
De migratie is het goedkoopste moment om structuur te repareren, zoals onze implementatiegids ook voor eerste projecten aangeeft, maar het is het verkeerde moment om een verrijkingsprogramma te starten. Weersta de neiging om alles op te schonen. Voor de vaste regels na de go-live, zie productdatakwaliteit en governance.
Big bang of gefaseerd overstappen?
| Big bang | Gefaseerd | Parallel draaien | |
|---|---|---|---|
| Wat het is | Alle data en alle kanalen gaan in één overstapvenster over | Eén productfamilie, merk, markt of kanaal tegelijk | Beide PIM's draaien, het nieuwe voedt de kanalen terwijl het oude als referentie blijft |
| Past als | Eén bron, een gemiddelde catalogus, weinig kanalen, een vaste einddatum van het contract | Meerdere bronnen, veel kanalen of markten, of een team dat niet lang kan stilliggen | Kanalen met veel risico, of als de business bewijs wil voordat er wordt omgeschakeld |
| Grootste risico | Alles faalt tegelijk; de rollback moet volledig zijn | Een tijd lang voeden twee systemen de kanalen; iemand moet bepalen welk product waar staat | Redacteuren werken beide systemen bij, of het verkeerde |
| Vereist | Volledige proefmigraties, een geteste rollback, een korte contentbevriezing | Een duidelijke verdeling per deel en een integratie die uit beide kan lezen | Het oude PIM strikt read-only, en een einddatum |
De meeste PIM-naar-PIM-overstappen komen uit op een gefaseerde aanpak met een korte parallelle periode per deel: verplaats één productfamilie of één kanaal, reconcilieer, schakel om en verplaats dan het volgende. Wat je ook kiest, stap elke keer met dezelfde volgorde over: bevries wijzigingen, draai de laatste load, draai een delta voor alles wat sinds de laatste proefmigratie is veranderd, reconcilieer en schakel daarna de kanalen in een vaste volgorde om. Leg de go/no-go-criteria en het rollbackpad vast vóór het overstapweekend, niet tijdens.
Hoe bewijs je dat er niets verloren is gegaan?
Met een reconciliatietabel die je vóór de eerste proefmigratie afspreekt en na elke load draait. Vergelijk het nieuwe PIM met de bevroren baseline, niet met het live oude PIM, want dat blijft veranderen.
| Check | Methode | Slaagregel |
|---|---|---|
| Aantal records per objecttype | Tel producten, productmodellen, varianten, categorieën en assets in baseline en doelsysteem | Gelijk, of elk verschil verklaard door een geschreven besluit om te migreren of te laten vallen |
| Vulgraad per attribuut | Aandeel producten met een waarde, per attribuut | Gelijk aan de baseline, of hoger waar een standaardwaarde is afgesproken |
| Vulgraad per locale | Hetzelfde, per locale voor vertaalbare attributen | Geen locale lager dan in de baseline |
| Optie- en eenheidswaarden | Unieke waarden per attribuut, gemapt via de regel | Geen waarde buiten de toegestane lijst; geen ongemapte bronwaarde |
| Variantstructuur | Parents, children en variantassen per familie | Zelfde aantal children per parent; assen kloppen met de mapping |
| Relaties | Aantal per relatietype; relaties die naar ontbrekende producten verwijzen | Aantallen gelijk; nul kapotte relaties |
| Assetkoppelingen | Assets per product, rol en volgorde; bestanden die openen | Aantallen gelijk; nul kapotte koppelingen; steekproef van bestanden opent |
| Exacte waarden bij lastige gevallen | Vergelijking veld voor veld voor een vaste set lastige producten | 100% gelijk, of elk verschil herleid tot een transformatieregel |
| Kanaaloutput | Export vanuit het nieuwe PIM naar elk kanaal, vergeleken met de laatste export uit het oude | Geen afgewezen producten die de oude export niet had |
| Akkoord van de business | Categorie-eigenaren beoordelen hun steekproef in het nieuwe PIM | Afgetekend per proefmigratie |
De set lastige gevallen is het nuttigste onderdeel. Kies een paar dozijn producten die de lastige hoeken van je catalogus vertegenwoordigen: de meeste varianten, de meeste relaties, de langste teksten, deels vertaalde locales, producten met veel assets en een paar met bekende dataproblemen. Komen die intact door, dan doen de makkelijke producten dat bijna altijd ook.
Hoeveel proefmigraties? Minstens twee volledige, en drie bij een complexe catalogus, die elk eindigen met een afgetekende reconciliatie. Een dalend aantal verschillen over de proefmigraties heen is het signaal dat je klaar bent. Onze zustersite pimselection.com beschrijft dezelfde volgorde van profileren, opschonen, mappen, proefdraaien en overstappen in haar gids over datamigratie, PIM Atlas heeft een stapsgewijs overzicht van PIM-datamigratie, en de Nederlandse zustersite pimsysteem.nl beschrijft datamigratie stap voor stap.
Wat verandert er als je Akeneo, Salsify, inriver of Pimcore verlaat?
De exportkant bepaalt hoeveel werk de extractie is. De tabel laat zien wat de eigen documentatie van elke leverancier vermeldt, gecheckt op 7 november 2026. Hij gaat over het verlaten van elk platform; is een ervan je doelsysteem, lees dan de importdocumentatie op dezelfde manier.
| Bron-PIM | Gedocumenteerde exportroutes | Waar je op let | Bron |
|---|---|---|---|
| Akeneo | Exportprofielen voor producten, productmodellen, families, categorieën en attributen als CSV of XLSX, met een optie om mediabestanden in een archief mee te nemen; asset families exporteren als CSV of XLSX met een optioneel archief van de bestanden; een REST API voor producten, productmodellen, family variants, attributen, opties, associatietypen, categorieën, reference entities, assets en regeldefinities | Exports met labels in plaats van codes kun je niet opnieuw importeren, dus exporteer codes. Associatiekolommen verschijnen alleen als minstens één geëxporteerd product een associatie heeft. De gecombineerde export van producten en productmodellen staat vermeld voor de edities Advanced en Premium. Assets die als medialinks zijn opgeslagen, exporteren als URL's, niet als bestanden. We vonden geen export van de geschiedenis | Akeneo Help Center, Akeneo API |
| Salsify | Export loopt via de API voor alle data, producten, digital assets, attributen en attribuutwaarden; producten als XLSX, CSV of JSON, de volledige export als JSON of JSONL | API-toegang hangt af van je licentietype. Productexports leveren standaard leaf products; vraag de hiërarchie expliciet op. De gedocumenteerde export van digital assets geeft assetrecords, geen bulkdownload van de bestanden, dus plan hoe je de binaire bestanden ophaalt | Salsify developer docs: export overview |
| inriver | Niet geverifieerd: het documentatieportaal van inriver opende op 7 november 2026 niet voor onze tools | Vraag inriver of je partner welke export alle entiteitstypen dekt, hoe koppelingen tussen entiteiten en specificaties worden geëxporteerd, en hoe resources (assets) worden geëxporteerd | Niet gedocumenteerd op de pagina's die we konden openen |
| Pimcore | Datahub File Export schrijft data-objecten naar CSV, XML of JSON; het standaard endpoint van de Datahub is GraphQL; voor maatwerk in import en export raadt Pimcore zijn PHP API aan | Een File Export-configuratie dekt één data-objectklasse. Assetvelden exporteren als pad of thumbnail, niet als bestand. De export heeft het object-ID als kolom nodig als je later wilt bijwerken. We vonden geen documentatie over het exporteren van versiegeschiedenis | Pimcore Datahub File Export, External system interaction |
Aan de importkant is dezelfde documentatie nuttig. De JSON-import van Salsify verwacht een vaste volgorde (header, attributen, attribuutwaarden, digital assets, producten), met assets waarnaar per URL wordt verwezen en relaties binnen het productrecord. De Data Importer van Pimcore leest CSV-, JSON-, XML-, XLSX- en SQL-bronnen en schrijft naar data-objecten via een mapping met create- of update-strategieën, en de documentatie zegt niet dat hij assetbestanden importeert. Stap je over naar Akeneo, dan verwachten de importprofielen codes, nog een reden om codes uit je bron te exporteren.
Daaruit volgen twee praktische regels. Exporteer met codes en identifiers, nooit met weergavelabels. En behandel assets als een aparte stroom: maak een lijst van de bestanden, hun koppelingen met producten en hun rollen, en controleer na de load dat de bestanden openen.
Kies je het doelsysteem nog, dan vergelijken onze alternatievenpagina's de opties per startpunt: alternatieven voor Akeneo, alternatieven voor Salsify en alternatieven voor Plytix.
Contract en timing: opzegtermijnen en overlap
Een migratieplan dat het contract negeert, eindigt met een overstap onder druk. Reken terug vanaf drie datums:
- De opzegdatum van het oude PIM. Controleer de opzegtermijn en de verlengingsdatum in het abonnement. Moet je maanden vóór de verlenging opzeggen, dan moet het besluit om te vertrekken vallen voordat het nieuwe systeem zich heeft bewezen.
- De overlap die je nodig hebt. Het oude PIM moet read-only beschikbaar blijven tijdens de laatste proefmigratie, de overstap en minstens één foutloze publicatiecyclus op elk kanaal. Reken die overlap mee, als korte verlenging of als onderdeel van de opzegtermijn.
- Het exportvenster. Laat schriftelijk bevestigen dat je tot de laatste dag van het contract alle data kunt exporteren, inclusief assets, en in welk formaat. Sommige SaaS-contracten beperken de toegang na de einddatum.
Controleer ook wie eigenaar is van de connectoren en het maatwerk die op het oude PIM zijn gebouwd. Koppelingen die een partner heeft gebouwd, moeten misschien opnieuw worden gebouwd, en dat werk hoort in het budget naast de licentie van het nieuwe systeem. Onze gids voor een PIM-RFP bevat vragen voor de nieuwe leverancier over ondersteuning bij de migratie, en de KatanaPIM-podcast over PIM-migratie behandelt scoping, eigenaarschap en fasering vanuit de praktijk.
Hoe we dit hebben beoordeeld
Deze gids combineert de migratiestappen die PIMvendors gebruikt in selectie- en implementatieprojecten met de eigen documentatie van elke leverancier. We openden op 7 november 2026 de export- en importdocumentatie van Akeneo, Salsify en Pimcore en legden vast wat die vermeldt. Het documentatieportaal van inriver opende die dag niet voor onze tools, dus de rij voor inriver bevat vragen in plaats van feiten. We hebben de stappen afgestemd op de migratiegidsen van onze zustersites pimselection.com, PIM Atlas en pimsysteem.nl, die dezelfde volgorde van profileren, mappen, proefdraaien, reconciliëren en overstappen volgen. We noemen geen doorlooptijden, faalpercentages of kosten, omdat die afhangen van je catalogus en geen bron die we konden controleren ze zo vermeldt dat ze naar jouw project over te zetten zijn.
PIMvendors is een onafhankelijk platform voor PIM-selectie. Exportopties veranderen met nieuwe releases, dus controleer de actuele opties bij de leverancier voordat je de extractie plant.
Bronnen
- Akeneo Help Center, Export your data, gecheckt op 7 november 2026.
- Akeneo Help Center, Export your products and product models, gecheckt op 7 november 2026.
- Akeneo Help Center, Export your assets, gecheckt op 7 november 2026.
- Akeneo, REST API reference en product concepts, gecheckt op 7 november 2026.
- Salsify developer documentation, Overview, Export overview en JSON import format, gecheckt op 7 november 2026.
- Pimcore documentation, Datahub File Export en de basisconfiguratie daarvan, gecheckt op 7 november 2026.
- Pimcore documentation, Data Importer, Datahub en External system interaction, gecheckt op 7 november 2026.
- pimselection.com, PIM data migration, gecheckt op 7 november 2026.
- PIM Atlas, PIM data migration, gecheckt op 7 november 2026.
- pimsysteem.nl, Datamigratie, gecheckt op 7 november 2026.
Hoe je verder gaat
Veelgestelde vragen
Hoe migreer je van het ene PIM naar het andere zonder data te verliezen?
Inventariseer alles wat het oude PIM bevat en bevries een read-only baseline-export. Map het oude datamodel attribuut voor attribuut op het nieuwe, met een geschreven regel voor elk veld. Draai minstens twee volledige proefmigraties, drie bij een complexe catalogus, en reconcilieer na elke proefmigratie de aantallen en waarden per attribuut. Stap over met een bevriezing en een deltaload, en houd het oude PIM read-only tot het nieuwe foutloos naar elk kanaal heeft gepubliceerd.
Hoe lang duurt een PIM-naar-PIM-migratie?
Dat hangt af van het aantal producten, attributen, talen, assets en koppelingen, en vooral van hoe schoon de brondata is. Plan de kalender rond de proefmigraties in plaats van rond de laatste load: elke proefmigratie vraagt tijd om te laden, te reconciliëren en te herstellen. Vraag de nieuwe leverancier of integrator naar een referentiemigratie van vergelijkbare omvang en hoeveel proefmigraties daarvoor nodig waren.
Moet ik productdata opschonen voor of na de migratie?
Verdeel het per type probleem. Verwijder dubbele records, ongeldige identifiers en uitgefaseerde producten in de bron, voordat je extraheert. Los structurele problemen op, zoals gemengde eenheden of vrije tekst die een optielijst hoort te worden, tijdens de migratie met regels. Bewaar verrijking, zoals nieuwe omschrijvingen of attributen die het oude PIM nooit had, voor na de go-live, anders houdt de migratie nooit op.
Hoe weet ik dat er niets verloren is gegaan bij de migratie?
Reconcilieer, ga niet op je oog af. Vergelijk tussen de bevroren baseline en het nieuwe PIM het aantal records per objecttype, de vulgraad per attribuut en per locale, het aantal relaties en varianten, de assetkoppelingen en een checksum of exacte vergelijking van waarden voor een steekproef van lastige gevallen. Spreek de slaagregel voor elke check af vóór de eerste proefmigratie, en laat de business owner het resultaat aftekenen.
Wanneer kan ik het oude PIM uitzetten?
Pas als elk kanaal minstens één normale publicatiecyclus zonder fouten vanuit het nieuwe PIM heeft gedraaid, de reconciliatie is geslaagd en de go/no-go-criteria die je vóór de overstap hebt afgesproken zijn gehaald. Houd het oude PIM tot dan read-only, zodat niemand in twee systemen werkt, en controleer de opzegtermijn zodat het contract niet afloopt vóór de datum waarop je het uitzet.
Kan ik versiegeschiedenis en workflowstatussen migreren?
Meestal niet in een bruikbare vorm. Versiegeschiedenis en auditlogs staan niet tussen de exportopties die Akeneo, Salsify en Pimcore documenteren, en workflowstatussen zijn zelden één op één over te zetten, omdat elk PIM workflow anders modelleert. Archiveer de geschiedenis uit het oude PIM in een leesbaar formaat voor auditdoeleinden, en start openstaande workflows opnieuw in het nieuwe PIM.
Is een PIM-naar-PIM-migratie anders dan een eerste PIM-implementatie?
Ja. Bij een eerste implementatie komt de data uit spreadsheets en het ERP, en is veel ervan nog ongestructureerd. Bij een PIM-naar-PIM-migratie heeft de bron al een datamodel, dus het werk bestaat uit het vertalen van het ene model naar het andere: families, varianten, relaties, assets, locales en kanaalregels. Juist in die vertaling raakt data kwijt, omdat twee systemen deze zaken zelden op dezelfde manier modelleren.
Diagnose
Heb je eigenlijk wel een PIM nodig?
Draai eerst de complexiteitsindex voordat je software budgetteert of een systeemintegrator inhuurt.
Budget
Maak een eerste TCO-berekening
Zet de vorm van je catalogus in minder dan tien minuten om in een kostenrange voor drie jaar.