When a security application changes, saying “the data has been exported” can make the work sound complete. Yet the delivered files may not open, attachments may be difficult to match to reports, or earlier corrections may no longer be understandable. What matters to the organisation is that information requiring retention can be found and read by authorised people when needed.
This question should arise before a contract ends. When evaluating a new record system, examining a sample of what can be exported at exit is a useful procurement step.
A record may contain more than visible text
Rutgers University researchers Jantz and Giarlo discuss managing content, context and change history together within a digital-preservation architecture. [1] Their archival study does not experimentally validate the security checklist below; it provides a conceptual basis for considering what an export must preserve. As the Digital Preservation Coalition's guidance also makes clear, file-integrity checks do not replace assessment of readability and content. [2]
Define the delivery scope first
The relevant client functions should determine which records remain within required retention periods and who may access them. Choose a scope consistent with the applicable retention and disposal arrangements rather than copying everything indefinitely.
Specify the period, record types and attachments included in the package. If a record number, creation time, subsequent correction time and responsible role are separate fields, preserve their meanings. Consider sharing restrictions for personal data and security-sensitive details.
Open the files in the receiving environment
Check that a report readable in the old system can also be read by an authorised receiving user. Are dates and Turkish characters correct? Does a long description appear in full? Can the file only be opened with software whose licence is about to end?
If spreadsheet columns have moved, the data may appear present while its meaning has changed. An event time and an entry time, for example, should not be merged under one ambiguous heading. Where time zones or date conventions matter, include that information in the export documentation.
Demonstrate that attachments remain connected
Consider a hypothetical package where reports and photographs are delivered in separate folders. If the relationship between each photograph and report exists only in an internal link in the old application, copying the folders does not preserve it.
During acceptance, the attachment associated with a selected report should open. Missing attachments and those excluded from the agreed scope should be identified separately. Sample checks can cover different records, such as those at the start and end of a period. Document the sampling scope; opening a few files does not establish that the entire package is error-free.
Combine technical integrity with an acceptance decision
The IT team can carry out appropriate integrity checks for unchanged file copies. Where a format conversion has taken place, a different file is expected; retain a conversion record and compare the relevant content.
A short acceptance record can identify:
- The transferred period, record types and package version.
- The scope of opening, searching and attachment-matching checks.
- Missing records, affected fields and issues requiring correction.
- The authorised access location and responsible function.
- Rechecking after correction and the acceptance decision.
Plan closure of old access and disposal of archives in light of applicable retention requirements and the acceptance result. Successful delivery means that the required records remain usable with their intended context intact.
