Replacing an existing PIM: contract exit, data portability, migration

When does replacing your PIM make sense?

Replace a PIM when the platform cannot meet validated requirements, and fix governance first when the problems are ownership and data. A new platform inherits undefined ownership, poor source data and missing processes from the old one.

Valid reasons to replace a PIM include:

• The data model cannot represent your products, such as complex variants, bundles or configurable items.
• The platform cannot scale to your catalogue, languages or channels.
• Syndication or regulatory requirements, such as packaging data under PPWR, are not supported.
• The vendor's roadmap, support or commercial terms no longer fit.
• The platform reaches end of life or a forced migration to a new product generation.

Test these reasons before deciding. Write the requirements the old platform fails, and check them against the same 4-domain checklist PIMvendors uses in selections. Some failures turn out to be configuration choices from the first implementation.

If replacement is right, treat it as a new selection. The implementation pillar explains why most failed implementations were decided during selection. The same applies the second time, with one advantage: you know your data and your users far better than before.

How do you plan the contract exit?

Plan the exit backwards from the old contract's notice date, renewal date and export terms. These dates set the latest point for decisions and the window for migration.

Request a test export early, ideally at least a quarter before the notice date. A test export shows what the vendor's tools actually deliver: which entities, which formats, which history. Gaps found early can be negotiated or worked around. Gaps found after notice put the migration under time pressure. The timeline guide shows how to plan backwards from a fixed exit date.

Align the old exit with the new contract. The new platform's licence often starts before the old one ends. Plan the overlap in the business case and in the negotiation with the new vendor, for example through a delayed licence ramp-up.

What does the EU Data Act change for switching SaaS PIMs?

The EU Data Act gives customers of cloud services, including SaaS, rights to switch providers within set periods and at falling cost. The rules sit in Regulation (EU) 2023/2854.

According to analyses by Maples Group and Travers Smith:

• The mandatory switching contract terms apply to existing and new contracts from 12 September 2025.
• SaaS is in scope, alongside PaaS and IaaS.
• The customer's notice period is capped at two months.
• A transitional period of up to 30 calendar days follows, with limited extension options.
• A data retrieval period of at least 30 calendar days follows the transition.
• Switching charges are limited to direct costs until 11 January 2027 and banned from 12 January 2027.
• Exportable data includes input and output data and metadata created through the customer's use of the service.

Two cautions apply. Proportionate early termination fees in fixed-term contracts may still apply. Custom-built services are partly exempt, and a Digital Omnibus proposal would widen some exemptions for older contracts. Whether and how these rules apply to your PIM contract is a question for counsel.

Use the Data Act as a floor in negotiations. Ask the old vendor how it implements these terms, and write equivalent exit terms into the new contract.

Which data must leave the old PIM?

Everything the business needs to operate and to prove past decisions must leave the old PIM in a usable format. Product records are only part of it.

Change history is the hardest. Few PIMs can import another system's history as native history. Decide whether to archive it in a readable format, keep the old system read-only for a retention period or accept the loss. Regulatory data may require an audit trail, so involve compliance owners in that decision.

The data migration guide covers profiling, mapping and rehearsals for the move itself.

How do you migrate between PIMs?

Migrate between PIMs as a redesign with a migration attached, and move channels one at a time. A one-to-one copy imports old compromises into the new platform.

Start with a review of the old data model. Document what it handles badly: variant structures, inheritance, classification versions, channel-specific attributes. Design the new model against current requirements, then map old to new. The data model design page explains the design principles.

Plan the channel sequence:

1. Choose a first channel or market with manageable risk and clear ownership.
2. Migrate its scope, switch its exports to the new PIM and set the old scope to read-only.
3. Stabilise, then move the next channel.
4. Switch supplier imports and ERP integration at an agreed point, so data enters one system only.
5. Decommission the old PIM after the retention period.

Parallel running needs strict rules. Each product must have one master system at any moment. Dual maintenance of the same product in two systems creates conflicts that are expensive to resolve.

Keep the parallel period short. Licence overlap and duplicate maintenance cost money every month. The illustrative multinational replatforming pattern shows how a phased channel sequence works at scale.

What should the new contract say about exit?

The new contract should define the exit you would want next time, while negotiating power is highest. Buyers rarely think about exit at signature, and that is when it is cheapest to secure.

Exit terms to include:

• Export of all data elements in the table above, in documented, machine-readable formats.
• A free test export once per year, or on request before renewal.
• Exit assistance hours at stated rates.
• Read-only access for an agreed period after termination.
• Notice periods and fees consistent with the Data Act, where it applies.
• Deletion confirmation after the retrieval period.
• Ownership of configuration documentation produced by the vendor or partner.

The PIM contract checklist contains these terms alongside other platform clauses. In negotiation, anchor high on exit terms; vendors often concede them more easily than price.

Test the exit terms once during the first year. A test export that works on day 300 is evidence that the clause holds. Record the result in the governance log.