How to Migrate from One PIM to Another Without Losing Data (2026)

Last updated: 7 November 2026.

You migrate from one PIM to another without losing data by inventorying and freezing the source, mapping the old data model to the new one attribute by attribute, and running at least one full rehearsal migration before the real one. After each rehearsal you reconcile counts and values per attribute against the frozen baseline, and you keep the old PIM read-only until the new one has published cleanly to every channel. Two or three rehearsals are safer than one for a catalog with many variants, languages or relations.

This guide is for teams that already run a PIM and are moving to another one: Akeneo to Pimcore, Salsify to inriver, an in-house PIM to SaaS, or any other pair. It covers what typically gets lost, the inventory and mapping work, the cutover choice, how to prove nothing is missing and what each of the big platforms documents about exporting your data. If this is your first PIM, start with the PIM implementation guide instead, because a first implementation starts from spreadsheets and an ERP, not from another data model.

What gets lost in a PIM migration, and why?

A PIM-to-PIM migration is a translation between two data models. The product rows usually arrive. What goes missing is the structure around them, because no two PIMs model it the same way. Our guide to the product data model explains the building blocks; these are the ones that break.

What gets lost	How it happens	What to check
Attributes	A field has no target in the new model, or two old fields merge into one without a rule	Every source attribute has a mapped target, an explicit "drop" or an archive decision
Option lists and units	Codes become labels, labels change, units are mixed in one field	Allowed values and units match per attribute after load
Variants	Multi-level variant structures get flattened, or the axis that defines a variant is lost	Parent and child counts, variant axes and inherited values per family
Relations	Associations, cross-sells, accessories, bundles and spare-part links point to identifiers that changed	Relation count per type, and no relation pointing to a missing product
Assets and their links	Files move but the link to the product, the role (main image, data sheet) or the order is lost	Asset count per product, asset role, sort order, and files that open
Translations	Locales that are only partly filled are skipped, or fallback rules differ	Fill rate per attribute per locale, before and after
Channel rules	Completeness rules, channel-specific values and export mappings live in the old PIM's configuration, not its data	A written list of rules per channel, rebuilt and tested in the new PIM
Workflow states	"In review" or "approved" has no equivalent, so products arrive with the wrong status	Status per product, and open tasks restarted on purpose
History	Version history and audit logs are rarely exportable in a form the new PIM can load	An archived, readable copy kept for audit

Two causes sit behind most of these rows. First, the identifiers change: if the new PIM generates its own internal IDs, every relation, asset link and integration that referred to the old ID has to be remapped. Agree one stable business identifier, such as the SKU or a GTIN, that exists in both systems and drives every lookup. Second, the configuration is not data. Completeness rules, channel mappings and workflow definitions are often the result of years of small decisions, and they do not come out of an export.

What should you inventory before you move anything?

Start with a list of everything the old PIM holds, who owns it and whether it moves. Then take a baseline export and freeze it: a read-only copy of the source at a known moment. Every later check compares against that baseline, so it must not change.

Data object	Where it usually lives	Owner	Migrate?
Products and SKUs	PIM core	Product data team	Yes, active products; decide on discontinued ones
Product models, families and variant structures	PIM data model	PIM administrator	Yes, remodelled for the target
Attributes, option lists and units	PIM data model	PIM administrator with category owners	Yes, after profiling
Categories and channel taxonomies	PIM, sometimes the commerce platform	Category or e-commerce manager	Yes, own tree; channel mappings rebuilt
Relations, bundles and spare-part links	PIM relations	Category owners	Yes
Assets and their metadata	PIM, built-in DAM or a separate DAM	Marketing or content team	Yes, with links and roles
Translations per locale	PIM values	Localisation owner	Yes, with fill rates measured first
Supplier data and onboarding mappings	PIM or supplier portal	Purchasing or data onboarding team	Mappings: rebuild; raw files: archive
Completeness and validation rules	PIM configuration	PIM administrator	Rebuild and test; not exportable as data in most PIMs
Channel exports, feeds and connectors	PIM configuration or integration layer	E-commerce and IT	Rebuild per channel
Workflow states and open tasks	PIM workflow	Data stewards	Restart in the new PIM
Version history and audit log	PIM	Compliance or IT	Archive, rarely migrate
Users, roles and permissions	PIM administration	PIM administrator	Recreate, do not copy blindly

Discontinued products deserve a decision of their own. Migrate them only if a process needs them in the PIM, such as spare-part lookups, warranty or a B2B portal that still shows them. Everything else can go to an archive that someone can read without the old system.

Profile before you map

Before you design the mapping, measure the source. Per attribute: how often it is filled, which formats and units appear, how many duplicates and orphan relations exist and how complete each locale is. A field that is filled for a handful of products in a large catalog is a decision, not a mapping. Profiling turns the "clean before or after" question below into a list with names on it.

How do you map the old data model to the new one?

Write the mapping down, attribute by attribute, and give every line an owner. A spreadsheet is fine, as long as it has these columns:

Column	What it holds
Source object and attribute	The code in the old PIM, not the label
Target object and attribute	The code in the new PIM, or "drop" or "archive"
Transformation rule	Unit conversion, split, merge, code to option, text to number
Locale and channel scope	Whether the value is per locale, per channel or global, in both systems
Default or fallback	What happens when the source is empty
Owner	The business person who decides what the field means
Test case	One real product that proves the rule works

Map the structure before the values. Decide first how the new PIM represents families, variant levels, relations and asset roles, because those decisions change the shape of every product. Then map attributes inside that structure. Use codes, not labels, on both sides: labels change with language and editing, codes stay stable.

Three mapping decisions cause most of the rework later:

1. Variant levels. If the old PIM has two variant levels (for example model, colour, size) and the new one models variants differently, decide where each attribute lives before the first load, because moving values between levels later means reloading.
2. Scope. An attribute that is per channel in one system and global in the other forces a choice: keep one value, or create channel-specific attributes. Make that choice explicitly.
3. Relations. Load parents before dependents: reference data, then categories, then products, then relations and assets. A relation that points to a product not yet loaded fails silently in many importers.

Clean before or after the move?

Both, split by type of problem. This keeps the migration finite and the new PIM clean.

Type of problem	When to fix it	Why
Duplicates, invalid identifiers, retired products	Before extraction, in the source	They multiply every later step and break relations
Mixed units, free text that should be an option list, inconsistent formats	During the migration, with written transformation rules	The rule documents the decision and runs the same way in every rehearsal
Missing enrichment: new attributes, better descriptions, extra images	After go-live, in the new PIM	It is new work, not migration, and it would keep the cutover date moving

The migration is the cheapest moment to fix structure, as our implementation guide notes for first projects too, but it is the wrong moment to start an enrichment programme. Resist cleaning everything. For the ongoing rules after go-live, see product data quality and governance.

Big bang or phased cutover?

	Big bang	Phased	Parallel run
What it is	All data and all channels move in one cutover window	One product family, brand, market or channel at a time	Both PIMs run, the new one feeds channels while the old one is kept as reference
Fits when	One source, a moderate catalog, few channels, a fixed contract end date	Several sources, many channels or markets, or a team that cannot pause for long	Risky channels, or when the business wants proof before switching
Main risk	Everything fails at once; the rollback has to be complete	Two systems feed channels for a while; someone must own which product lives where	Editors update both systems, or the wrong one
Must have	Full rehearsals, a tested rollback, a short content freeze	A clear split per slice and an integration that can read from both	The old PIM strictly read-only, and an end date

Most PIM-to-PIM moves land on a phased approach with a short parallel run per slice: move one product family or channel, reconcile, switch it, then move the next. Whatever you choose, cut over with the same sequence every time: freeze edits, run the final load, run a delta for anything changed since the last rehearsal, reconcile, then switch the channels in a fixed order. Decide the go/no-go criteria and the rollback path before the cutover weekend, not during it.

How do you prove nothing was lost?

With a reconciliation table that you agree before the first rehearsal and run after every load. Compare the new PIM against the frozen baseline, not against the live old PIM, which keeps changing.

Check	Method	Pass rule
Record counts per object type	Count products, product models, variants, categories, assets in baseline and target	Equal, or every difference explained by a written migrate/drop decision
Fill rate per attribute	Share of products with a value, per attribute	Equal to the baseline, or higher where a default was agreed
Fill rate per locale	The same, per locale for localisable attributes	No locale lower than in the baseline
Option and unit values	Distinct values per attribute, mapped through the rule	No value outside the allowed list; no unmapped source value
Variant structure	Parents, children and variant axes per family	Same number of children per parent; axes match the mapping
Relations	Count per relation type; relations pointing to missing products	Counts equal; zero broken relations
Asset links	Assets per product, role and order; files that open	Counts equal; zero broken links; sample of files opens
Exact values on hard cases	Field-by-field comparison for a fixed set of difficult products	100% match, or each difference traced to a transformation rule
Channel output	Export from the new PIM to each channel, compared with the last export from the old one	No rejected products the old export did not have
Business sign-off	Category owners review their sample in the new PIM	Signed per rehearsal

The hard-case set is the most useful part. Pick a few dozen products that represent the difficult corners of your catalog: the most variants, the most relations, the longest texts, partly translated locales, products with many assets and a few with known data problems. If those come through intact, the easy products almost always do.

How many rehearsals? At least two full ones, and three for a complex catalog, each ending with a signed reconciliation. A falling number of differences over the rehearsals is the signal that you are ready. Our sister site pimselection.com describes the same profile, cleanse, map, rehearse and cutover sequence in its data migration guide, and PIM Atlas has a step-by-step PIM data migration overview.

What changes when you leave Akeneo, Salsify, inriver or Pimcore?

The export side decides how much work the extraction is. The table shows what each vendor's own documentation states, checked on 7 November 2026. It covers leaving each platform; when one of them is your target, read its import documentation the same way.

Source PIM	Documented export routes	What to watch	Source
Akeneo	Export profiles for products, product models, families, categories and attributes as CSV or XLSX, with an option to include media files in an archive; asset families export as CSV or XLSX with an optional archive of the files; a REST API covering products, product models, family variants, attributes, options, association types, categories, reference entities, assets and rule definitions	Exports with labels instead of codes cannot be re-imported, so export codes. Association columns only appear when at least one exported product has an association. The combined product and product model export is listed for the Advanced and Premium editions. Assets stored as media links export as URLs, not files. We found no history export	Akeneo Help Center, Akeneo API
Salsify	Export runs through the API for all data, products, digital assets, attributes and attribute values; products as XLSX, CSV or JSON, the full export as JSON or JSONL	API access depends on your licence type. Product exports default to leaf products; request the hierarchy explicitly. The documented digital asset export gives asset records, not a bulk download of the files, so plan how you fetch the binaries	Salsify developer docs: export overview
inriver	Not verified: inriver's documentation portal did not open for our tools on 7 November 2026	Ask inriver or your partner which export covers all entity types, how links between entities and specifications are exported, and how resources (assets) are exported	Not documented on the pages we could open
Pimcore	Datahub File Export writes data objects to CSV, XML or JSON; the Datahub's default endpoint is GraphQL; for custom import and export Pimcore recommends its PHP API	A File Export configuration covers one data object class. Asset fields export as a path or thumbnail, not the file. The export needs the object ID as a column if you want to update later. We found no documentation on exporting version history	Pimcore Datahub File Export, External system interaction

On the import side the same documentation is useful. Salsify's JSON import expects a fixed order (header, attributes, attribute values, digital assets, products), with assets referenced by URL and relations inside the product record. Pimcore's Data Importer reads CSV, JSON, XML, XLSX and SQL sources and writes to data objects through a mapping with create or update strategies, and its documentation does not say that it imports asset files. If you are moving to Akeneo, its import profiles expect codes, which is another reason to export codes from your source.

Two practical rules follow. Export with codes and identifiers, never with display labels. And treat assets as a separate stream: list the files, their links to products and their roles, and check after load that the files open.

If you are still choosing the target, our alternatives pages compare the options per starting point: Akeneo alternatives, Salsify alternatives and Plytix alternatives.

Contract and timing: notice periods and overlap

A migration plan that ignores the contract ends with a cutover under pressure. Work backwards from three dates:

1. The notice date of the old PIM. Check the notice period and the renewal date in the subscription. If notice must be given months before renewal, the decision to leave has to be made before the new system is proven.
2. The overlap you need. The old PIM has to stay available, read-only, through the last rehearsal, the cutover and at least one clean publication cycle on every channel. Price that overlap in, either as a short extension or as part of the notice period.
3. The export window. Confirm in writing that you can export all data, including assets, until the last day of the contract, and in which format. Some SaaS contracts limit access after the end date.

Also check who owns the connectors and custom code built on the old PIM. Integrations built by a partner may need to be rebuilt, and that work belongs in the budget next to the licence of the new system. Our PIM RFP guide has questions for the new vendor about migration support, and the KatanaPIM podcast on PIM migration covers scoping, ownership and phasing from practice.

How we evaluated

This guide combines the migration steps PIMvendors uses in selection and implementation projects with each vendor's own documentation. We opened the export and import documentation of Akeneo, Salsify and Pimcore on 7 November 2026 and recorded what it states. inriver's documentation portal did not open for our tools that day, so the inriver row lists questions instead of facts. We aligned the steps with the migration guides on our sister sites pimselection.com, PIM Atlas and pimsysteem.nl, which follow the same sequence of profiling, mapping, rehearsal, reconciliation and cutover. We give no durations, failure rates or costs, because they depend on your catalog and no source we could check states them in a way that would transfer to your project.

PIMvendors is an independent PIM selection platform. Export options change with releases, so confirm the current options with the vendor before you plan the extraction.

Sources

• Akeneo Help Center, Export your data, checked 7 November 2026.
• Akeneo Help Center, Export your products and product models, checked 7 November 2026.
• Akeneo Help Center, Export your assets, checked 7 November 2026.
• Akeneo, REST API reference and product concepts, checked 7 November 2026.
• Salsify developer documentation, Overview, Export overview and JSON import format, checked 7 November 2026.
• Pimcore documentation, Datahub File Export and its basic configuration, checked 7 November 2026.
• Pimcore documentation, Data Importer, Datahub and External system interaction, checked 7 November 2026.
• pimselection.com, PIM data migration, checked 7 November 2026.
• PIM Atlas, PIM data migration, checked 7 November 2026.

Where to go from here

Both tools are free and independent of any vendor.

Not sure you need a PIM yet?

A short check that shows whether a dedicated PIM helps your catalog, or whether spreadsheets and ERP still do the job.

Check if a PIM fits

Ready to compare vendors?

Answer questions about your scale, sector and must-haves and get a ranked shortlist.

Build my vendor shortlist