Migrate Inspection Records Without Losing Their Context

Define what users must still be able to do

Begin the migration plan with the tasks that depend on the inspection records. Users may need to find the current report for an asset, retrieve an earlier revision, open native examination data or explain which drawing applied at the time of work. Write these tasks down before selecting export formats or counting files.

A migration can move every visible document while breaking the relationships that make the documents useful. The completion criteria should therefore include retrieval and interpretation, not just transfer. Identify the people who can judge those tasks: record owners, technical reviewers, regular users and system administrators may each see different failure modes. Their involvement belongs in the plan from the beginning.

Establish a bounded source inventory

List the source systems, folders, date ranges and record types included. Identify exclusions and the reason for each. A shared drive may contain controlled reports, drafts, convenience copies and unrelated personal material. Do not assume that everything in the folder has the same status or retention requirement.

Create an identifiable baseline for the extraction. Record its date, scope and responsible owner. If the source continues to change, the migration needs a way to capture those changes later. Without a baseline, the team cannot distinguish an import omission from a record that was added after the first transfer.

Preserve metadata as part of the record package

NARA publishes metadata requirements for transfers of permanent federal electronic records. Those requirements do not automatically govern a private inspection archive, but they demonstrate that contextual information accompanies the record rather than being an optional decoration. [1]

Identify the metadata needed for your use: asset identity, report status, revision, author or issuing organization, relevant dates and links to attachments may all matter. Confirm the meaning of each field. A date called completed could refer to fieldwork, report review or administrative closeout. Preserve that distinction instead of mapping every date into one convenient destination column.

Separate migration from record correction

Moving records and correcting their contents are different activities. If the source contains an incorrect identifier, the migration team should not silently repair it based on a plausible guess. Record the discrepancy and send it to the authorized owner for resolution. Preserve the original evidence and the basis for any approved correction.

This separation protects both the historical record and the migration evidence. If a value changes, a later reviewer should be able to tell whether it changed because of an authorized correction, a defined transformation or an error. A clean destination dataset is not trustworthy if nobody can explain how it differs from the source.

Map fields with their meaning and constraints

For each source field, record the destination, any transformation and the handling of missing or unusual values. Consider identifiers with leading zeros, dates with ambiguous order, text fields containing units and status values that have no direct equivalent. These details can be lost even when the import process reports success.

Have the relevant record owner review the mapping. A software specialist can describe the conversion mechanics, but may not know whether two inspection statuses mean the same thing. If no suitable destination exists, retain the source information in an agreed form and document the limitation. Do not force distinct meanings into one category merely to satisfy the new system's layout.

Preserve relationships between records

Inspection evidence often forms a connected package: an asset links to a work order, the work order links to a report, and the report links to attachments or native files. Revisions and amendments add further relationships. Test those connections explicitly in the destination system.

Avoid relying solely on filenames to rebuild the structure. Similar names can occur in different projects, and one report may cover several identified items. Use the source relationships where available and record how they are represented after migration. If the source relationship is uncertain, preserve the uncertainty rather than inventing a definitive link.

Distinguish exact copies from transformed records

Some files may be copied without changing their content. Others may be converted, indexed, extracted or imported into structured fields. These paths need different checks. A byte-level comparison can help verify an unchanged copy, but it cannot establish that a transformed record preserves all relevant meaning.

The North Carolina archives guidance discusses maintaining metadata and activity information through migration and conversion. Its public-records context is specific; the practical application here is to retain evidence of what happened to each record. [2] Record transformations, software versions and known limitations so that later users can distinguish source material from derived access copies.

Test native data in the receiving environment

A native examination file may require particular software, versions or supporting files to remain usable. Confirm those needs before replacing the source system. Merely storing the file in a new repository does not prove that an authorized reviewer can open and interpret it later.

Select representative native datasets and test them with the intended users. Record the viewing environment and any compatibility issues. If an access copy is created, preserve its relationship to the native source and state what it omits. Do not replace the only retained technical dataset with a simplified image unless the authorized record requirements explicitly support that decision.

Choose a representative migration trial

Run a trial on a bounded set that includes the important variations in the archive. Consider different periods, file formats, revision histories, attachment structures and known problem cases. A trial containing only recent, clean records may prove little about the older material that presents the greatest challenge.

Document why the trial set was selected and what it cannot establish. The appropriate sampling and validation depth depend on the archive and its obligations; this guide supplies no universal sample size. Use the trial to refine mappings, estimate exception work and improve the user checks before committing the full dataset to cutover.

Worked example: the duplicate report identifier

In a fictional migration, two historical projects contain a report numbered R-104. The old folders distinguish the projects, but the destination import expects the report number to be unique. A simple import either rejects one record or merges the two under a single identity. Both outcomes would damage the archive's meaning.

The team defines a destination key that preserves the project relationship and keeps the original report number as source information. It tests searches from both the project and report views and verifies the attachments. The example illustrates why successful field transfer is not enough; identity rules must reflect the real records rather than the assumptions of the receiving application.

Reconcile counts without treating them as the whole test

Compare source and destination counts at meaningful levels: projects, report versions, attachments or other relevant record groups. Explain differences caused by approved exclusions, packaging changes or duplicate handling. An unexplained total is a warning even when the destination contains approximately the expected volume.

Then test content and relationships. A matching count can still include one duplicated file and one missing file. A changed count can be legitimate if one source package is represented by several related destination records. Reconciliation should make these differences understandable and traceable rather than forcing every system into an identical number.

Manage exceptions as records of work

Create an exception register for failed imports, ambiguous mappings, missing attachments and unusable files. Each entry should identify the source, destination status, issue, owner and next action. Keep unresolved records distinguishable from successfully migrated records so that users do not assume the archive is complete.

Prioritize exceptions according to their effect on required use and retention obligations. The appropriate owner should decide whether a limitation is acceptable, requires correction or prevents cutover. Do not close an exception merely because the software can no longer reproduce the error. Closure needs evidence that the underlying record problem has been resolved or formally accepted with a stated limitation.

Test user access and confidentiality

Review who can see, change, export and administer the migrated records. Access permissions may not transfer directly between systems. A destination that makes records easier to find can also expose information to people who did not previously have authority to view it. Have the relevant data and system owners approve the access design.

Test representative user roles rather than relying only on an administrator account. Confirm that authorized users can complete their tasks and that restricted material remains appropriately controlled. Keep access testing separate from technical content validation so that a successful retrieval does not conceal an inappropriate permission setting.

Plan the period when both systems exist

During migration, staff may continue creating reports or correcting records in the old system. Decide where new work belongs and how changes are captured for the final reconciliation. Communicate the arrangement clearly so that users do not update both systems independently and create competing histories.

If a temporary freeze is required, define its scope, duration and authorized exceptions. The organization's operational needs determine whether such a freeze is feasible. The migration team should not impose it without coordination. Record changes that occur after the baseline and verify that they are included or deliberately excluded at cutover.

Define cutover and recovery decisions

Cutover is the point at which the new system becomes the agreed working source for the defined scope. Specify the evidence required, the decision owner and the unresolved exceptions permitted at that point. A vendor's completed import message is useful input, but it is not automatically the owner's acceptance decision.

Prepare a recovery plan in case the new system cannot support essential tasks. Consider both the records and the work created during the cutover period. A recovery that restores an old copy while losing recent reports is incomplete. Test the practical route with the responsible IT and record owners before it is needed.

Keep the old environment until authorized disposition

Do not delete source records simply because the destination appears usable. Retention and disposal depend on the organization's applicable obligations, approvals and migration evidence. Identify who can authorize disposition and what conditions must be satisfied. This guide does not set retention periods or provide legal authority to destroy records.

Where the old environment remains available temporarily, define its status and access. Users should know whether it is a historical reference or still a place for active updates. Uncontrolled parallel use can undo the benefits of migration by creating new discrepancies after the destination has been accepted.

Record the migration evidence package

Retain the scope, source baseline, mapping decisions, transformation information, validation results, exceptions and cutover approval in an organized package. The package should explain the migration without requiring access to the memories of the original project team. Link it to the destination archive's administrative records.

Keep the evidence proportionate and usable. A large collection of unexplained logs is less helpful than a clear index pointing to the relevant records. Include the known limitations and any follow-up obligations. If future users discover a discrepancy, they should have a practical route to investigate how the affected record reached the new system.

Use the worksheet to run a retrieval rehearsal

Complete the worksheet for a trial package, then ask a regular user to perform a realistic task in the destination. For example, locate the current report for an asset, identify a superseded revision and open the associated native dataset. Observe where they need information that the migration plan did not preserve.

Record the result as evidence and revise the plan where necessary. The exercise is not a substitute for all required validation, but it exposes usability gaps that file counts miss. Use controlled or authorized sample data, and avoid distributing sensitive records beyond the people involved in the review.

Verify search behavior after indexing

A record may be present in the destination but difficult to find because the search index interprets identifiers differently. Test exact identifiers, common alternate forms and the filters users normally rely on. Pay attention to punctuation, leading zeros and scanned documents whose searchable text comes from automated recognition. Search results should not be treated as an authoritative transcription of the underlying report.

If a search fails, determine whether the record is missing, its metadata is mapped incorrectly or the index has not processed it as expected. Those causes require different corrections. Preserve the controlled report while correcting the retrieval mechanism through the authorized system process.

Document known search limitations in the handover guidance. Users need a fallback retrieval route for records that cannot be located through ordinary text search. A migration is more useful when people understand how to recover a difficult item than when the project simply declares that every file is searchable.

Hand over ownership of the new archive

At completion, identify who maintains the mappings, resolves later exceptions, controls access and supports retrieval. Provide the relevant documentation and a route for reporting problems. A migration project can end while the archive continues to need active management; that continuing responsibility should be explicit.

NDT Connect's learning guides and record-planning worksheets can help organize the work, but they are not a native inspection archive or migration service. Use an appropriate system and authorized specialists for the actual transfer. The successful outcome is a record collection whose identity, context and limitations remain understandable after the old system is no longer the daily point of reference.