DPP Data Migration: Moving to a New Platform

Šis raksts vēl nav pieejams jūsu valodā, tāpēc tas tiek rādīts angļu valodā.

Why Organisations Need to Migrate DPP Data

Digital Product Passport platforms are a relatively new category of software, and the market is evolving rapidly. Organisations that adopted early-stage solutions may find that their current platform no longer meets their needs as regulatory requirements tighten, product catalogues grow, or integration demands increase. Others may be consolidating from multiple departmental tools onto a single enterprise platform, or moving from a bespoke in-house system to a managed SaaS solution.

Whatever the trigger, migrating DPP data is a high-stakes operation. Product passports are regulatory compliance instruments, if data is lost, corrupted, or rendered inaccessible during migration, you risk non-compliance with the EU Ecodesign for Sustainable Products Regulation (ESPR). Public-facing passport URLs must continue to resolve correctly, QR codes printed on products and packaging must still work, and the historical audit trail of passport changes must be preserved.

This guide provides a structured methodology for planning, executing, and validating a DPP data migration, drawing on database migration best practices and the specific requirements of product passport systems. Whether you are moving between commercial platforms or transitioning from a custom-built solution, the principles outlined here will help you execute the migration with confidence.

Pre-Migration Assessment and Planning

Every successful data migration begins with a thorough assessment of what you are moving, where it is coming from, and what the target platform expects. Skipping this phase is the single most common cause of migration failures, because unexamined assumptions about data formats, completeness, and dependencies invariably surface as errors during execution.

Your pre-migration assessment should cover the following areas:

• Data inventory, Catalogue every data object in your current platform: products, passport records, material compositions, compliance certificates, supplier declarations, document attachments, scan analytics, and user accounts. Record the count, average record size, and any relationships between objects.
• Schema comparison, Map the source platform's data model against the target platform's schema. Identify fields that map directly, fields that require transformation, fields present in the source but absent in the target (and vice versa), and any structural differences such as flat versus nested representations.
• Data quality audit, Run completeness and validity checks on the source data. How many product records have all mandatory ESPR fields populated? Are there orphaned records, duplicate entries, or fields containing placeholder values? It is far more efficient to clean data before migration than to import dirty data and attempt remediation on the target platform.
• Dependency mapping, Identify external systems that read from or write to your current DPP platform. ERP integrations, e-commerce plugins, supply chain portals, and public passport URLs all need to be redirected or reconfigured as part of the migration.
• Compliance timeline, Determine whether any regulatory deadlines constrain your migration window. If new ESPR delegated acts take effect during your planned migration period, you may need to ensure the target platform supports the updated data requirements before you begin.

For a thorough understanding of DPP data structures and how they relate to compliance requirements, review our guide to DPP data architecture.

Data Extraction Strategies

Extracting data from your source platform cleanly and completely is the foundation of a successful migration. The extraction method depends on what your current platform offers, API access, database export capabilities, or file-based export tools.

API-based extraction is the preferred approach when available. It allows you to programmatically retrieve records in a structured format (typically JSON or XML), paginate through large datasets, and filter by criteria such as product category or last-modified date. Build your extraction scripts to be resumable, if the process fails partway through, you should be able to restart from the last successfully extracted record rather than beginning from scratch.

Database-level extraction, connecting directly to the source platform's database, provides the most complete access to data but carries risks. You may encounter undocumented schema elements, internal reference IDs that have no meaning outside the platform, or data stored in serialised blobs that require platform-specific deserialisation logic. Only use direct database access when APIs are insufficient or unavailable, and always work from a read replica or backup to avoid impacting the production system.

File-based extraction using CSV, Excel, or JSON exports is common with smaller platforms. The limitation is that file exports often flatten hierarchical data, lose relationship information, and may not include all fields. If your current platform only offers file exports, supplement them with manual data capture for any attributes not included in the export.

Regardless of the extraction method, generate checksums or record counts at the point of extraction and verify them after loading into the target platform. This end-to-end validation ensures that no records were lost or duplicated during the transfer.

Schema Mapping and Data Transformation

Schema mapping is where the intellectual heavy lifting of migration occurs. You must define precisely how every meaningful field in the source system translates to a field in the target system, accounting for differences in naming conventions, data types, enumeration values, and structural organisation.

Create a formal mapping document, a spreadsheet or configuration file that specifies, for each target field, the corresponding source field, any transformation logic required, and a fallback value for cases where the source data is absent. Version-control this document and treat it as a first-class artefact of the migration project.

Common transformation scenarios include the following:

• Enumeration value translation, The source platform might use "recyclable", "partially_recyclable", "not_recyclable" whilst the target expects "FULL", "PARTIAL", "NONE". Build a lookup table for every enumerated field.
• Unit standardisation, Material weights in kilograms versus grams, dimensions in centimetres versus millimetres. Convert all values to the target platform's expected units during transformation.
• Identifier remapping, Internal IDs from the source platform (auto-increment integers, UUIDs) will not match the target platform's ID scheme. Maintain a cross-reference table that maps old IDs to new IDs so that relationships between records (e.g., product-to-passport, passport-to-document) are preserved.
• Nested structure changes, If the source stores material composition as a flat comma-separated string but the target expects a structured array of objects with material name, percentage, and classification, you need a parser that reliably handles edge cases in the source data.
• Date and time format normalisation, Ensure all timestamps are converted to a consistent format (ISO 8601 is recommended) and that timezone information is preserved or correctly converted.

Write automated tests for your transformation logic covering both typical records and edge cases. A single mapping error applied to thousands of records creates a remediation problem that can delay your entire migration timeline.

Preserving Public URLs and QR Code Functionality

One of the most critical, and most frequently overlooked, aspects of DPP migration is ensuring that existing public passport URLs continue to work after the transition. Products already in the market carry QR codes, NFC tags, or printed URLs that consumers and regulators use to access passport information. If those links break, you have a compliance failure and a customer experience problem simultaneously.

There are three strategies for preserving URL continuity:

• URL structure preservation, If the target platform allows you to configure custom URL paths, replicate the exact URL structure used by the source platform. For example, if passports were accessible at /p/{uuid}, ensure the target platform serves content at the same paths with the same UUIDs.
• HTTP redirects, Set up 301 (permanent) redirects from the old URL structure to the new one. This works when the target platform uses a different URL format, provided you maintain the redirect infrastructure indefinitely (or at least for the expected product lifetime).
• GS1 Digital Link resolution, If your passports use GS1 Digital Link URIs (e.g., /01/{gtin}/21/{serial}), ensure the target platform supports this standard. GS1 Digital Link provides a layer of indirection that can simplify platform migrations, because the resolver service can be updated to point to the new platform without changing the URIs embedded in products.

Before executing the migration, compile a complete inventory of every public URL associated with an active passport. After migration, run an automated link checker that verifies every URL returns a 200 status code and serves the correct passport data. This verification step is non-negotiable, it is your primary assurance that the migration has not broken the public-facing function of your DPP system.

For background on how product passports work from a consumer perspective, see our complete guide to Digital Product Passports.

Migration Execution: Phased Approach vs Big Bang

The execution strategy for your migration falls on a spectrum between two extremes: a big-bang cutover, where all data moves at once and the old platform is decommissioned immediately, and a phased migration, where data moves incrementally whilst both platforms run in parallel.

A big-bang approach is simpler to coordinate but riskier. It requires a maintenance window during which both platforms are unavailable, and if anything goes wrong, rollback means reverting everything. This approach suits smaller datasets (fewer than a thousand products) where the migration can be completed and validated within a few hours.

A phased approach reduces risk by migrating data in batches, perhaps one product category at a time, or one geographical market at a time. During the parallel-running period, the old platform continues to serve existing passports whilst the new platform handles newly migrated data. This requires careful routing logic (typically at the URL resolver or load balancer level) but gives you the ability to validate each batch before proceeding to the next.

For most organisations, a hybrid approach works best:

• Migrate historical and inactive product records first as a low-risk rehearsal.
• Migrate active product records in batches, validating each batch before proceeding.
• Run both platforms in parallel for a defined period (typically two to four weeks), with the old platform in read-only mode.
• Switch DNS or URL routing to the new platform once all batches are validated.
• Maintain the old platform in read-only archive mode for a further period as a safety net.

Whichever approach you choose, document a detailed runbook that specifies every step, the person responsible, expected duration, validation criteria, and rollback procedure. Rehearse the migration at least once in a staging environment using production-equivalent data before attempting the real thing.

Post-Migration Validation and Reconciliation

Post-migration validation is where you prove that the migration succeeded. This is not a cursory spot-check, it is a systematic verification that every record arrived at the target platform complete, accurate, and functional.

Your validation checklist should include the following:

• Record count reconciliation, Compare the number of products, passports, documents, and associated records in the target platform against the source. Any discrepancy must be investigated and resolved.
• Field-level validation, For a statistically significant sample of records (at minimum 10%, or all records if the dataset is small enough), compare every field value between source and target. Automated comparison scripts are essential here.
• Relationship integrity, Verify that all relationships between records are intact. Every passport should link to its correct product. Every document attachment should be associated with the right passport. Every historical version should be accessible.
• Public URL testing, As described earlier, verify that every public passport URL resolves correctly and serves the expected content.
• Integration testing, If ERP or e-commerce integrations were reconfigured to point at the new platform, send test transactions through each integration and verify correct processing.
• User acceptance testing, Have representatives from key stakeholder groups (compliance, product management, supply chain) access the new platform and confirm that their workflows function as expected.

Document the results of each validation step and obtain formal sign-off from the migration project sponsor before decommissioning the source platform. Retain a complete backup of the source platform data for a minimum of twelve months after migration, as a safeguard against issues that surface after the validation period. For regulatory compliance guidance, consult our article on the EU ESPR regulation explained.

Rollback Planning and Risk Mitigation

No migration plan is complete without a rollback strategy. Despite thorough preparation, unforeseen issues can arise during execution, data corruption, integration failures, or performance problems on the new platform, that necessitate reverting to the source system.

Your rollback plan should define the following:

• Rollback trigger criteria, Specific, measurable conditions that warrant a rollback decision. For example: more than 1% of public URLs returning errors, integration failure rates exceeding a threshold, or critical data quality issues affecting compliance-mandatory fields.
• Rollback procedure, Step-by-step instructions for reverting URL routing, DNS changes, and integration endpoints back to the source platform. This procedure should be tested during your migration rehearsal.
• Data synchronisation during rollback, If the new platform was live for any period and received new data (new products created, existing passports updated), that data must be captured and applied to the source platform as part of the rollback. This is the most complex aspect of rollback planning and argues strongly for keeping the source platform in a state where it can resume operations at short notice.
• Communication plan, Define who needs to be notified if a rollback occurs, including internal stakeholders, integration partners, and potentially regulators if the rollback affects public passport availability.

Risk mitigation extends beyond rollback planning. Consider maintaining a parallel-run period where both platforms serve live traffic, with a traffic splitter directing a small percentage of requests to the new platform initially and gradually increasing the proportion as confidence grows. This canary deployment pattern, borrowed from software release engineering, significantly reduces the blast radius of any migration defects.

Building for Future Portability

The effort and risk involved in DPP data migration should inform how you architect your passport data going forward. Adopting standards-based data formats, maintaining clean and well-documented schemas, and ensuring your platform provides comprehensive export capabilities will make any future migration significantly less painful.

Practical steps to improve future portability include the following:

• Use standardised identifiers wherever possible, GTINs, GS1 Digital Link URIs, and ISO-standard material codes are more portable than proprietary internal identifiers.
• Store passport data in open formats, JSON-LD with schema.org vocabularies or industry-standard ontologies ensures that your data is self-describing and interpretable by any compliant platform.
• Maintain a comprehensive API, Ensure your current platform provides full CRUD API access to all passport data, not just the subset exposed through the user interface.
• Document your data model, Maintain up-to-date documentation of your passport schema, including field definitions, valid values, relationships, and business rules.
• Implement regular export and backup procedures, Scheduled full exports to a platform-independent format serve as both disaster recovery and migration readiness measures.

The DPP landscape will continue to evolve as the ESPR's delegated acts define requirements for additional product categories and as interoperability standards mature. Organisations that treat their passport data as a strategic asset, portable, well-structured, and standards-compliant, will be best positioned to adapt to these changes without disruptive platform migrations. For a practical starting point, see our guide on creating your first Digital Product Passport with portability in mind from the outset.