Switching DPP Providers: Keeping Product Data and Identifiers Usable

Plan for a future switch from the start

A Digital Product Passport may be needed for many years. Contracts, IT systems and service providers can change during that time. It is therefore worth checking at the outset how data and responsibilities can be handed over later.

The question is not simply whether an export button exists. Product identifiers, evidence, relationships and access rules must remain understandable and usable outside the current environment.

Within the ESPR framework, Article 10 refers to open standards, interoperable data formats and transferability without dependency on a provider, among other requirements. This does not mean every practical provider switch will automatically be effortless. The handover needs both organisational and technical preparation. Source: Regulation (EU) 2024/1781, Articles 10 and 11.

1. Define what a complete export must contain

A table of visible text can lose important context. Define which elements are needed for a passport to remain usable.

These may include:

• structured data fields with units and language information,
• product, model, batch or individual item identifiers,
• associated documents and supporting evidence,
• relationships between products and components,
• provenance information and necessary version information,
• documented roles and access rules.

Which information must and may be handed over depends on the applicable rules, the purpose and existing rights. Not every item of internal operational information belongs in a public or external export.

2. A readable format alone is not enough

CSV and JSON are widely used formats. However, even a technically readable file can be unusable in practice without field definitions, value lists and relationship keys.

Ask for a sample export with documentation. A receiving organisation should be able to tell whether a number represents a mass, a proportion or a measurement, and which product it belongs to.

Also check whether references can still be resolved over time. An export that refers only to protected files in a customer account that will later be closed is not a reliable handover of the evidence itself.

3. Distinguish the identifier from the web address

The unique product identifier and the web address currently being opened have different purposes. During a switch, clarify which elements remain stable and who controls the connection from the data carrier to the passport.

Before signing a contract, ask:

• Who manages the domains and redirects being used?
• Who can change the destination of an existing data carrier?
• Will labels on products already delivered remain usable?
• What dependencies on the previous provider remain?
• Which transition and redirect services are agreed?

A new platform offers little help if codes on products already sold lead only to a discontinued access point. Test the connection all the way from the physical product to the correct data set.

4. Recheck access rights during the handover

An export can move information outside its previous protection context. An internal export file is therefore not automatically suitable for unrestricted import into a publicly accessible environment.

Before transferring data, map it to the intended recipients and purposes. Check how permissions are implemented in the target system. User names or technical role names may not be directly transferable.

The access rights required for the relevant product group remain decisive. A migration should neither accidentally expose protected information nor interrupt required access.

5. Agree responsibilities and a transition period

A successful switch needs a clear process. Who provides the final approved export? Who checks completeness? Who decides the cutover time and takes responsibility for subsequent data maintenance?

Also agree how changes during migration will be handled. Will source data be frozen briefly, or will there be a final reconciliation? Without such a rule, the data can diverge between export and launch of the target system.

Contractual points to clarify include scope of services, deadlines, costs, export assistance and the treatment of data after the contract ends. The specific arrangements must fit the availability and retention requirements for the product concerned.

6. Use an actual reimport as an acceptance test

A practical test is the strongest evidence of transferability. Export a representative data set and have it imported into an independent test environment or by the intended recipient.

Then compare more than record counts. Sample units, languages, evidence, relationships and access rights. Include a product with several variants and a record that has subsequently been corrected.

Document differences and how they are resolved. This turns “export is possible” into a verifiable handover capability.

Backups, exports and the registry serve different purposes

A backup supports recovery. An export supports reuse in a different context. Registration fulfils the applicable registration requirements. These tasks can be related, but they do not automatically replace one another.

The European Commission explains that the EU DPP Registry contains identifiers and registration data, while detailed product information is provided in a decentralised way. A registry entry is therefore not a complete migration package for product data. Source: European Commission – DPP Registry.

Four questions for your next provider discussion

1. Can we receive a documented sample export, including the necessary supporting evidence?
2. How will identifiers and existing data carriers remain usable during a switch?
3. What assistance and costs are agreed for the handover?
4. How will we test completeness, access rights and availability in the target system?

Answering these questions early reduces future dependencies and also makes internal system changes easier. Traceable data and clear responsibilities provide a sound foundation, as our article on DPP data quality explains.

Are you planning a Digital Product Passport and want to account for the long-term usability of your data? Contact SimpleDPP to discuss your starting point.