How Are Passport Data Migrated and Kept Portable?

Software migration and data portability cover moving passport records, field catalogues, identifier histories and audit trails from one system to another, or from a legacy product data system into a passport system, without loss of meaning, history or access control. Portability is a continuity requirement as well as a commercial safeguard: an operator who cannot move passport data cannot change vendor, cannot recover from a hosting failure, and cannot meet the Article 78 continuity duty after a vendor or operator change. Migration should therefore be designed as a tested, reversible process, not as a one off export at the end of a contract.

Migration failure takes a predictable form. Field meanings shift, history is dropped, identifiers are regenerated, access tiers are flattened, and the new system looks complete while the old history is lost. Each failure is avoidable by mapping fields, preserving history, preserving identifiers and testing the round trip before the live migration. A migration plan that lists only the new system features, without a mapping and a test, is not a migration plan; it is a replacement hope.

What must be portable in a passport system?

Portable elements include the passport records themselves, the field catalogue, the identifier allocation history, the registry confirmation records, the audit trail, the access tier map and the evidence files that support each field. A system that exports passport values without the catalogue, history and tier map exports data without meaning, because the receiving system cannot tell which field is which, which value is current, or which actor may see the field. Portability must therefore be defined as the export of the record plus its meaning, history and controls, in a standard format.

A portability checklist should list each portable element, its format, its version and its completeness check. A checklist that lists only passport values is incomplete. A checklist with values, catalogue, history, tier map and evidence allows the receiving system to reconstruct the record with its controls intact. The checklist should be tested on a sample, with the receiving system demonstrating that it can read, display and update the sample under tier control.

How is a field mapping prepared?

A field mapping is prepared by listing every field in the source system, every field in the target system, and the mapping rule for each pair, including direct mapping, transformation, split, merge and no mapping with a reason. Transformation rules must state the unit, vocabulary or format change, with the conversion basis and the test that proves the conversion. A mapping that states only that fields are similar, without a rule, cannot be tested. A mapping with a rule per field can be tested field by field, and the test result can be filed.

Worked check: a source system stores capacity in milliampere hours and a target system stores capacity in ampere hours. The mapping states the division by one thousand, the test converts a sample value and checks the result, and the audit trail records the conversion. A mapping without the conversion rule would copy the milliampere hour value into the ampere hour field, overstating capacity by a factor of one thousand. The rule and the test prevent a unit error from becoming a passport error.

How is history preserved during migration?

History is preserved by exporting the full audit trail for each passport, including every field change with its old and new values, actor, reason and date, and by importing the trail into the target system as history, not as current values alone. A migration that imports only current values loses the evidence of how the record reached its current state, and an authority query about an earlier value cannot be answered. History preservation should be tested by querying the target system for an earlier value and comparing it with the source trail, for a sample of records.

History testing should cover a record with a repair update, a record with a life stage change, and a record with a supplier data correction, because each history type tests a different trail element. A test that covers only a simple record with no updates will pass even when the history export is broken. The test sample should be chosen to cover the history patterns that occur in the operator data, and the test result should be filed with the migration evidence.

How are identifiers preserved?

Identifiers must be preserved exactly during migration, with no regeneration, reformatting or reassignment, unless the Regulation and the registry process provide for a linked identifier change. A regenerated identifier breaks the carrier link, the registry link and the history link at once, and the resulting battery will appear as a new battery with no history. Migration testing must confirm that every identifier in the source system appears unchanged in the target system, with the same carrier resolution and the same registry entry, before the live migration proceeds.

Identifier preservation should be checked by a full reconciliation, not by a sample, because a single duplicate or missing identifier creates a chain error for that battery. The reconciliation should list source identifiers, target identifiers and any mismatch, with mismatches investigated and corrected before go live. A reconciliation that reports only a count, without listing mismatches, cannot show which batteries are affected. The full list is the evidence, and it should be retained.

How is migration tested and reversed?

Migration is tested by a trial migration on a copy of the data, followed by completeness, meaning, history, identifier and access tests in the target system, with the results filed and reviewed before the live migration. Reversal is provided by preserving the source system and its data until the target system has been verified in live operation for a defined period, with a rollback trigger and a rollback procedure documented in advance. A migration without a trial, or without a preserved source, cannot be reversed safely if the target system fails in live operation.

Trial and rollback planning should include a go live checklist, a verification period, a rollback trigger list and a communication plan for exchange partners and authorities where the migration affects resolution or access. A plan that covers only the technical export, without the verification period and rollback triggers, leaves the operator without a decision route when the target system behaves differently in live operation. The plan should be approved by the operator role responsible for passport accuracy, with the approval dated.

What exit and continuity clauses support portability?

Exit and continuity clauses in vendor contracts should require data export in the standard format, with the catalogue, history and tier map, within a stated period, and should require cooperation during migration and continuity after termination. As checked on 28 October 2026, the continuity duty in Article 78 applies to the responsible operator, and the vendor contract should support that duty rather than hinder it. A contract without an export clause leaves portability to negotiation at exit, when leverage is lowest. This guide gives general educational information only and is not individual legal advice. A reader with a specific battery or market decision should check the current Regulation text and any applicable delegated act, as checked on 28 October 2026, before acting.

This guide gives general educational information only and is not individual legal advice. A reader with a specific battery or market decision should check the current Regulation text and any applicable delegated act, as checked on 28 October 2026, before acting. Migration should be tested on a copy, verified in live operation, and reversible until the new system is proven.