A successful import message confirms that a process finished; it does not establish that the resulting information is complete, correctly related or suitable for engineering use. Verification provides the evidence needed to answer those questions. For geotechnical data, that evidence must address both individual values and the context that gives them meaning.
A borehole record can retain its description while losing its location reference. A laboratory result can retain its number while becoming linked to the wrong sample. This article explains how to verify a data migration through a structured review of records, relationships, units, coordinates and exceptions, ending with a documented acceptance decision.
Define the baseline and the expected result
Identify the exact source package used for conversion. Record its date, contents and relevant application or schema version. Keep it available for comparison. If reviewers compare against a live source that has changed since extraction, they may report differences that arose after migration rather than through it. That distinction needs to be visible.
Keep the approved mapping and scope beside the source baseline. Some differences may be intentional: identifiers may be standardized, units converted or duplicates excluded under an agreed rule. Verification should compare the result with that approved expectation. Literal equality is appropriate for some fields, while a documented transformation is the correct test for others.
Reconcile counts at several levels
Start with counts of included projects and boreholes, then move to samples, intervals, tests, observations and attachments within scope. Compare meaningful groups rather than relying only on an archive-wide total. Grouping by project or record type helps locate a discrepancy that would be difficult to investigate in a single large count.
Matching totals do not prove completeness. One missing record and one duplicate can produce the expected total. Use identifier matching to establish which records arrived and which did not. Where a source record becomes several destination records, or several records are intentionally combined, document the relationship so the apparent count difference has an explanation.
An illustrative reconciliation might begin with 120 source boreholes. If 118 are transferred and two are deliberately excluded as confirmed duplicates, acceptance depends on identifying those two and documenting the approval. Reporting “118 imported successfully” without the disposition of the other records leaves the completeness question unanswered. Counts should lead to record-level explanations.
Verify identifiers and parent-child relationships
Determine which combination of fields uniquely identifies each source record. A borehole name may only be unique within a project. A sample number may repeat between investigations or laboratories. Preserve enough context to distinguish those records, especially if the destination uses a different identifier scheme from the source.
Trace complete relationships through selected examples. Follow a project to its borehole, a borehole to its sample and a sample to its test results. Confirm that notes and attachments point to the intended record. Include cases with similar names and repeated identifiers because they are more likely to reveal an incorrect join or matching rule.
Retain a cross-reference when identifiers change. Reviewers should be able to move from a destination record back to its source without relying on memory or a filename guess. That traceability also supports later investigation when a user asks why a historical result differs from an old report or appears under a new project name.
Check units and transformations explicitly
For each important numerical field, establish the source unit, destination unit and conversion rule. Compare selected transformed values with independently calculated expectations. Include zero values, negative values where legitimate, large values and precision-sensitive examples. Checking only a typical positive value may fail to reveal rounding or sign-handling problems.
Distinguish missing information from a genuine zero. Also preserve qualifiers and detection limits where relevant to the data type. A numeric field containing a qualified or textual result may need separate components in the destination. Converting it to a simple number without the accompanying meaning can materially change how a user interprets it.
Set tolerances according to the transformation and intended use. A floating-point representation difference is not necessarily a significant data error, while a unit mismatch can be serious even if the digits are identical. Document the tolerance and rationale. Do not choose a broad tolerance merely to make a comparison pass.
Review coordinates and elevation references
Compare both coordinate values and the information required to interpret them. Identify the coordinate reference system, datum, axis order and any transformation used. Check elevation references separately. Moving numbers into matching column names does not establish that the source and destination describe the same physical position.
Use a map comparison as a diagnostic alongside numerical checks. Look for systematic shifts, swapped axes, isolated points and clusters that have moved relative to known project geography. A point plotted in a plausible region is still not proof of correctness. The transformation and reference information must support the location, especially where local grids were used.
Where the source reference cannot be established, preserve and flag the uncertainty. Do not assign a coordinate system simply because it makes the points appear close to an expected site. Escalate the issue to the appropriate data owner and document any approved interpretation or restriction on using those records spatially.
Examine depths, intervals and descriptive content
Compare start and end depths, total depth and the association of samples or observations with intervals. Look for reversed intervals, unintended overlaps and records extending beyond the stated borehole depth. Some conditions may already exist in the source, so retain the distinction between an inherited issue and an error introduced by conversion.
Review long descriptions and special characters for truncation or altered meaning. Check line breaks where they separate important notes, and examine controlled-value translations alongside the original terms. A destination lookup may be more standardized than the source, but combining distinct descriptions into one code requires an explicit, reviewable decision.
Do not assume that every interval dataset follows the same rules. Lithology, sampling and observations may overlap legitimately in different ways. Apply checks appropriate to each record type and intended use. A generic rule that removes every overlap could change valid information while appearing to improve consistency.
Compare outputs without confusing appearance and content
Generate representative logs, tables or reports from the destination. Compare the essential information with the corresponding source output: identifiers, depths, descriptions, symbols, results and notes. Confirm that the output uses the intended template and settings. A missing field on a report may be a presentation issue rather than absent data.
Inspect the underlying records as well as the rendered output. A familiar-looking log cannot show every stored field or relationship. Likewise, a correctly transferred database may produce a different visual layout that remains acceptable for the agreed workflow. State whether acceptance concerns information equivalence, particular formatting requirements or both.
Use systematic checks and targeted professional review
Apply repeatable comparisons across the full included population where practical, then use targeted review to examine meaning and usability. Sampling should cover difficult transformations and important data types rather than being limited to convenient records. Record what was reviewed and why. A sample supports conclusions about its coverage, not an unlimited guarantee.
When a defect is found, investigate its possible reach. A single incorrect code may indicate a mapping rule affecting many records. Search for the same condition throughout the converted scope and repeat the relevant checks after correction. Treat the example as evidence of a potential class of problems until its cause and extent are understood.
Manage exceptions as decisions, not loose notes
Maintain an exception register with a unique issue reference, affected records, description, cause and owner. Add the proposed treatment and final disposition. Common outcomes include correction and retest, accepted limitation, exclusion with separate retention, or escalation for more information. Link supporting evidence so another reviewer can follow the decision.
Separate severity from frequency. A rare error involving the wrong borehole location may be more consequential than many minor display differences. Prioritize issues according to their effect on the intended use. A percentage-complete dashboard should never conceal an unresolved problem that prevents reliable interpretation of a critical part of the dataset.
Assemble evidence for acceptance
The acceptance package should identify the source baseline, destination version, mapping revision, tests performed and results. Include reconciliation summaries, representative comparisons and the exception register. State the scope of the review, the remaining limitations and who authorized release. Keep sufficient detail for an independent colleague to understand the basis of the decision.
Verification of transfer is distinct from confirming the scientific correctness of every historical observation. A migration can faithfully preserve information that was already questionable. Make that boundary explicit. Where professional review identifies a source problem, record it and agree its treatment rather than allowing the migration process to imply endorsement of the original data.
Make verification part of the migration plan
Agree the checks before full conversion so the source information and review resources will be available. GAEA’s Migration Center page describes reconciliation and professional review as parts of a controlled migration. Confirm the checks and deliverables included in your particular scope; unreleased Migration Center automation remains planned rather than a current guarantee.
Preparing acceptance criteria? Discuss your source records and required outputs with GAEA. A clear verification plan turns “the files imported” into a more useful conclusion: the agreed information was accounted for, reviewed and accepted for a defined purpose, with its limitations recorded.