A geotechnical data migration pilot is a controlled test of whether selected information can move into a new environment and remain useful. It should answer practical questions before the full archive is converted: are relationships preserved, are important values interpreted correctly, and can users produce the outputs they need?
A pilot is most valuable when it is designed to expose uncertainty. Converting the cleanest project and opening one attractive log may demonstrate a narrow workflow, but it does not establish readiness for a varied historical archive. This guide explains how to select samples, define checks and use the findings to make a documented decision about the next stage.
Establish what the pilot must prove
Begin with a short statement of purpose. For example, the pilot might test whether selected legacy borehole projects can support routine review and reporting in the proposed destination. Identify the relevant products, versions and users. State what lies outside the exercise, such as recreating every historical template or correcting all source-data defects.
Convert that purpose into observable outcomes. A reviewer should be able to locate each included project, follow a borehole to its samples, inspect required results and create an agreed report. Decide which outcomes are mandatory and which are exploratory. This prevents an interesting demonstration from being mistaken for acceptance of a complete production workflow.
Choose samples for coverage rather than convenience
Build the sample from your source inventory. Include the main database structures, software generations and reporting conventions represented in the planned migration. A typical project is useful because it tests everyday work. A difficult project is equally useful because it reveals how the process handles ambiguity or customization.
There is no universal number of projects that makes a pilot sufficient. A small, consistent archive may need fewer examples than a collection assembled through several acquisitions. Explain the reason for every selected sample. The record should show which source type, data relationship or business requirement each example tests, making untested areas easy to identify.
Include edge cases deliberately: repeated borehole names in different projects, unusually long descriptions, mixed units, missing identifiers, attachments and uncommon test types. Use actual representative records where permitted. If an artificial test case is needed, label it clearly and keep it separate from genuine project information so it cannot be mistaken for a historical observation.
Protect the source and isolate the trial
Run the pilot from a defined copy or export rather than an uncontrolled live database. Record the preparation date and identify any dependencies needed to interpret the package. Preserve a baseline that can be used for repeated comparisons. If the source changes during testing, document whether the next run uses the original baseline or an updated package.
Keep the pilot destination distinct from production records. Assign access appropriate to the review team and make the test status clear. Agree how trial data will be retained or removed after the exercise. These arrangements are practical controls against staff using a partially reviewed dataset as if it had already been approved for project work.
Agree mappings before interpreting results
Prepare a mapping register showing how important source fields become destination fields. Include data types, units, controlled values and relationships. Record intentional transformations such as identifier changes or unit conversions. A mapping that says only “copy depth” is incomplete if the source depth convention or destination unit differs.
Discuss unsupported content explicitly. The appropriate treatment may be a separate retained attachment, a custom configuration, a revised scope or exclusion with approval. Do not substitute a convenient destination field merely because it accepts the source text. Preserving characters without preserving meaning can create a misleading appearance of successful conversion.
Use examples to settle difficult choices. If two legacy codes appear similar, ask whether they truly represent the same condition before merging them. Record who approved the translation and why. The pilot then tests an agreed rule rather than allowing individual records to be handled differently according to undocumented judgment.
Write acceptance criteria that can be tested
Acceptance criteria should state the expected result, the method of checking it and the person responsible. For record completeness, the criterion might require every included borehole to have a destination counterpart or a documented disposition. For a transformed numerical value, specify the conversion and an appropriate comparison tolerance rather than demanding literal equality.
Distinguish critical failures from matters that can be resolved later. Missing sample relationships may prevent acceptance, while a minor report-spacing difference may be an agreed improvement item. This classification must reflect the intended use of the data. Avoid arbitrary thresholds that allow a small percentage of highly consequential errors simply because the overall success rate looks high.
Include a rule for exceptions. An issue should have an identifier, affected records, explanation, owner and disposition. A list of warnings is not the same as evidence that someone reviewed them. The acceptance record should make clear which issues were corrected, which limitations were accepted and which remain unresolved.
Run the conversion and capture what happened
Record the source package, destination version, configuration and mapping revision used for each run. Retain the available conversion messages and relevant logs. If a configuration changes, give the next run a distinct identifier. This lets the team connect a result to the process that produced it instead of comparing screenshots from uncertain versions.
Inspect the immediate result before beginning detailed technical review. Confirm that the expected projects are present and that the process did not stop partway through. Separate tool failures from source problems and mapping questions. Each category may need a different response, and combining them into one undifferentiated issue list makes resolution harder.
Reconcile records and relationships
Compare counts at meaningful levels: projects, boreholes, samples, tests and other included record types. Follow the identifiers from source to destination. Matching totals are a useful first signal, but they cannot prove that the correct records were transferred or linked. A missing record and an unintended duplicate can cancel each other in a total.
Trace selected complete chains through the dataset. Start with a project, open a borehole, find its sample and confirm the associated result. Include repeated names and complex cases from the sample design. Verify that attachments and notes remain associated with the correct parent record. These checks reveal errors that a table-by-table review may overlook.
Test technical values and normal outputs
Compare representative depths, intervals, units, coordinates, descriptions and qualified results. Where transformation was intended, compare against the approved expected value. Investigate whether a difference comes from the source, the conversion or presentation formatting. A displayed value rounded to two decimals should not be confused with loss of precision in the stored data.
Ask a normal user to complete a realistic task without the conversion specialist directing every step. Generate the required log or table and review whether essential information is present and understandable. Note missing configuration, training needs and data issues separately. A technically complete dataset can still require workflow preparation before staff can use it efficiently.
Correct, repeat and look for regressions
When a defect is found, establish its cause before correcting only the visible example. A wrong unit mapping may affect an entire class of records. Update the rule, rerun the relevant scope and repeat the affected checks. Also review previously successful cases that could be changed by the correction.
Keep a concise run history with what changed and why. Do not compare a corrected destination against an older source package without acknowledging the difference. Reproducibility is part of pilot quality: another authorized reviewer should be able to identify the inputs, apply the approved process and understand how the acceptance evidence was produced.
Make a documented decision about the next stage
A pilot can lead to three useful outcomes: proceed within the tested scope, revise and repeat, or pause until a prerequisite is resolved. A pause may be appropriate when source access is incomplete or a critical field has no agreed interpretation. Finding that problem early is a successful risk discovery, not evidence that the pilot was wasted.
The decision record should summarize coverage, results, unresolved issues and limitations. Identify who approved the outcome and what must happen before production. State clearly which source families were not tested. Approval of one database structure should not silently extend to a different structure merely because both were created by the same application.
Turn pilot findings into a production plan
Use the findings to refine effort, sequencing and review responsibilities. Group the archive into batches with similar characteristics and decide when users will review them. Establish how changes in active source projects will be captured before final cutover. Keep a defined route for handling new exceptions that were absent from the pilot.
GAEA’s Migration Center guidance recommends representative assessment and review. Confirm the supported tools and assistance applicable to your source. Unreleased centralized Migration Center capabilities remain planned; a pilot should test an available, agreed workflow rather than depend on a future feature being delivered by a particular date.
Planning a pilot? Discuss the source and target workflow with GAEA. Bring representative records, essential outputs and proposed acceptance criteria. The most useful result is a clear basis for the next decision, supported by evidence about the data your organization actually needs to use.