A QR code printed on a battery could still be scanned years after it leaves the factory. By then, the Digital Battery Passport provider might have changed, the original platform might have been replaced, or the battery itself might have entered a second stage of its life.
Will that QR code still work?
The answer depends on something that's easy to overlook when planning a Digital Battery Passport: the long-term management of the link behind the QR code.
You can move passport data between platforms, but that doesn't automatically mean the links printed on thousands of batteries will continue to work. Domain ownership, URL structure, redirects, and access to identifier mappings all play a key role.
With the EU Battery Regulation setting requirements for Digital Battery Passports from February 18, 2027, these decisions are worth making early. The goal isn't just to get a passport online. It's to maintain a reliable connection between a physical battery and its digital record as systems and service providers evolve.
What should you agree on before choosing a provider?
You don't need to design every technical detail yourself. But you should know how your QR codes will be managed throughout the battery's life.
Use the following questions to guide the conversation with your provider.
Make sure your technical team understands how the setup works and that procurement knows which responsibilities and services are included in the contract.
Most importantly, test the approach before relying on it in production.
Start with a small set of sample records. Generate QR codes, record their URLs, and verify that each code opens the correct passport. Then simulate a migration by changing the destination or moving the records to a test environment.
Scan the original codes again. Confirm that the links resolve, the records match the correct batteries, and the intended information remains accessible. Include unpublished records in the test if your production process requires labels to be printed in advance.
This gives you a practical view of the migration process while there's still time to address any gaps.
“A Digital Battery Passport is a long-term commitment to keeping product information accessible, not just a one-time implementation. The real question is whether the connection between a battery and its digital record will remain intact as systems, providers, and business relationships change. That’s why URL ownership and migration planning deserve the same attention as the passport data itself.”
- Jaqueline Laganaro, Head of Sales at Minespider
What happens to a QR code when you change providers?
First, it's useful to separate three elements that work together: the QR code, the URL it contains, and the Digital Battery Passport it leads to.
A QR code is a data carrier. When someone scans it, their device reads the encoded information, which commonly includes a web address. That address then directs them to the relevant online resource.
These elements serve different purposes:
- The QR code is the printed pattern attached to the battery or its packaging.
- The URL and unique identifier provide the address and identify the relevant battery or passport.
- The Digital Battery Passport contains the information associated with that battery, subject to the applicable access rights.
The distinction matters during migration. Moving the passport data to a new platform doesn't change the URL already printed on the battery. If that URL stops working, the passport might still exist, but the QR code no longer provides a reliable route to it.
For example, imagine that your QR codes point to addresses hosted by Provider A. You migrate your passport records to Provider B, but Provider A shuts down the original URLs. Anyone scanning an existing label could encounter a broken link.
Now imagine the original addresses remain active and their destinations can be updated to point to Provider B. The same printed QR codes can continue to work without replacing the labels.
The difference isn't the QR code itself. It's the infrastructure managing the connection behind it.
Can you use your own domain?
A custom domain or subdomain, such as passport.example.com, allows you to use your own web address for Digital Battery Passport URLs.
Minespider supports custom-domain setups, allowing passport links to use a customer’s domain. However, using your own domain doesn’t automatically guarantee long-term continuity. You also need to understand who manages the infrastructure behind it.
Before implementation, clarify who owns and manages the domain, DNS configuration, security certificates, and routing. Ask who operates the service that directs a scanned URL to the correct Digital Battery Passport and whether you can change that destination without relying on your provider.
This distinction becomes especially important if you migrate to another platform. Even if you control the domain, you may still depend on your provider if it operates the resolver or holds the only copy of the identifier-to-passport mappings.
The key is to agree on both domain ownership and operational control before labels are printed.
Can you print labels before creating the Digital Battery Passport?
Your manufacturing and labeling schedules don't always align with passport data preparation. You might need to print labels while supplier information is still being collected or before the full Digital Battery Passport record is ready.
In some implementations, QR codes can be generated from predictable product identifiers before a passport is complete or published. This can allow manufacturers to prepare labels in advance, but it depends on how the provider handles identifiers and URL resolution.
Before using this approach, agree on what happens when someone scans a code before the passport is available. The URL might lead to a temporary landing page or display a message explaining that the passport isn't ready yet.
You also need a reliable process for linking each identifier to the correct passport once it's published. Confirm how identifiers are assigned, how duplicate assignments are prevented, and whether the existing URL can be activated without replacing the label.
A small test can help you catch problems early: generate sample labels, scan them before publication, then scan them again once the passports are available. Check that each code resolves as intended and leads to the correct record.
Will the same QR codes work after migration?
Existing QR codes can continue to work after you change Digital Battery Passport providers, provided the URL encoded in each code remains active and can be directed to the passport at its new location.
The QR code itself doesn't need to change. What needs to change, or remain operational, is the infrastructure behind the link.
Whether this is possible depends on the URL structure, domain control, identifier mappings, and redirect or resolver arrangements. If the original URL belongs to your outgoing provider, continued access may depend on that provider maintaining the address or redirecting it. If the URL uses a domain you control, you may have more flexibility, provided you can also manage the routing and preserve the mapping to the correct passport.
Neither setup guarantees continuity on its own. Before committing to an approach, ask your provider to explain the migration process and demonstrate it with sample QR codes. Verify that the original codes still lead to the correct passports after the destination changes.
Who maintains redirects when you change providers?
A redirect sends a visitor from one URL to another. It might be configured on a web server, managed through a domain's hosting infrastructure, or handled by a dedicated resolution service.
Redirects can be managed by your organization, your Digital Battery Passport provider, or a separate resolver service. The right arrangement depends on your implementation.
What matters is knowing who operates the service, who can change destinations, and what happens when your provider relationship ends.
Agree on these responsibilities before implementation, including how long existing links will remain available after termination, what migration support is provided, and whether you can access the configuration and identifier mappings needed to maintain the links independently.
Document these arrangements in both the technical design and the contract. It's also worth considering what would happen if the provider became unavailable unexpectedly, rather than assuming a planned migration will always be possible.
What does the EU Battery Regulation mean for link continuity?
The EU Battery Regulation (Regulation (EU) 2023/1542) establishes requirements for Digital Battery Passports for in-scope electric vehicle batteries, light means of transport batteries, and industrial batteries with a capacity greater than 2 kWh from February 18, 2027.
Article 77(5) requires battery passport data to be based on open standards and be interoperable, transferable through an open interoperable data exchange network, free from vendor lock-in. The data must also be machine-readable, structured and searchable, in accordance with the essential requirements in Article 78.
These provisions make interoperability and continuity important considerations when selecting a solution. However, they shouldn't be interpreted as a guarantee that every provider-specific URL will automatically continue working after a migration. The technical arrangement still needs to support that outcome.
The Regulation also addresses passport availability if the responsible economic operator ceases to exist or ceases its activity in the EU. That requirement concerns the availability of the passport; it shouldn't be treated as a substitute for planning domain ownership, URL resolution, and provider transitions.
In practice, it's worth discussing these responsibilities with your provider alongside data portability and the ability to transfer passport records.
Keep the connection, even when the platform changes
Your Digital Battery Passport platform may evolve, and your service provider might not be the same one you use today in five or ten years. The QR codes already printed on your batteries, however, still need to lead users to the right information.
That's why link continuity deserves attention from the beginning.
You don't necessarily need to manage every component yourself. You do need a clear understanding of who controls the domain, how URLs are resolved, where identifier mappings are stored, and what happens when you move to another provider.
A QR code should connect your battery to its digital record not create a permanent dependency on the platform that first published it.
Plan for that connection before labels are printed, agree on responsibilities with your provider, and test the migration process while you still have time to make changes.
Planning QR Codes for the Long Term with Minespider
At Minespider, QR-code and URL strategies are agreed as part of the implementation. Depending on your requirements, custom-domain setups can be used for Digital Battery Passport URLs, including configurations where a QR code points to a URL on your own domain that directs users to a Minespider-hosted passport. In some implementations, this can also allow manufacturers to prepare labels before passport data is finalised, with the URL resolving to the relevant passport when it becomes available.
The focus is on planning the route behind the QR code, not just generating the code itself. We work with customers to align identifier and URL structures with their workflows, including how QR codes are linked to passport records and what happens before a passport is available. If later you change providers, continuity depends on who controls the domain, redirects, and identifier mappings. These responsibilities should be agreed on during implementation so you understand how links can be maintained or updated if the underlying platform changes.
