A geotechnical data migration begins well before the first import. The most useful early work is establishing what your organization owns, what it needs to preserve and how people will use the information afterward. Without that preparation, a straightforward transfer can become a succession of questions about missing files, unfamiliar codes and report differences.
This geotechnical data migration checklist helps project managers, technical reviewers and data administrators assemble a reviewable starting point. It is intended for archives containing boreholes, samples, laboratory results, monitoring information and related project records. Use it to prepare a migration assessment and pilot, then adapt the details to the source application and destination workflow.
1. Define the outcome before inventorying everything
Write down the business reason for the migration. Perhaps an older application is becoming difficult to maintain, a team wants to consolidate project archives, or historical information needs to support new investigations. Translate that reason into specific tasks users must perform after migration: find a project, open a borehole, review test results and produce an agreed output.
Separate mandatory outcomes from desirable improvements. Reproducing an essential client log may be necessary for acceptance, while redesigning every historical report may be a later project. This distinction helps prevent the migration from expanding into an unbounded database cleanup and reporting redesign. Assign each outcome an owner who can confirm whether the result is usable.
2. Build an inventory of sources and versions
List the applications, versions, database types and export formats in use. Include active project databases, archived copies and files maintained outside the main system. Record where each collection resides, who controls access and whether it can currently be opened. A filename alone may not establish which application or schema created the data.
Estimate project and record volumes, but label estimates clearly. Counts of folders, databases, boreholes and samples describe different things. A folder containing ten copied backups is not necessarily ten distinct projects. Identify likely duplicates without deleting them during initial discovery; decide which copy is authoritative only after reviewing its date, contents and ownership.
Include dependencies such as lookup lists, symbols, descriptor libraries, external documents and linked images. Some information may be referenced by a path rather than stored inside a database. Test a few links from an appropriate working copy. Discovering that attachments live on a retired shared drive is a preparation issue that should be resolved before conversion begins.
3. Preserve an identifiable source baseline
Create controlled copies or exports for assessment and keep the original records protected. Give the assessment package a date and version so everyone knows which material was reviewed. If live projects will continue changing, record how later additions and edits will be captured. Otherwise, a technically correct conversion may still omit work completed after the source copy was taken.
Agree who is responsible for backups and for testing recovery. A backup is useful only if the required files and dependencies can be restored. Retention requirements vary by organization and project, so document the applicable internal decision rather than assuming that a successful migration permits immediate deletion of the old environment.
4. Identify keys and relationships
Determine how the source connects projects, boreholes, samples, tests and observations. A borehole name may be unique within one project but repeated across the archive. A sample identifier may also require a project or borehole reference to establish its meaning. Record those relationships before proposing new naming conventions.
Prepare examples that expose ambiguity. Two projects might both contain BH-01, yet represent entirely different investigations. Combining them under one identifier would preserve a name while destroying context. Any renaming rule should retain a traceable link to the original identifiers and explain how related records will remain connected after migration.
5. Document units, coordinates and reference information
Record the units used for depths, elevations, measurements and laboratory results. Note whether units are stored explicitly or inferred from a project setting or report label. Blank unit fields deserve investigation; they should not automatically inherit the most common unit in the archive. Identify projects that use different conventions so the pilot can test them deliberately.
For coordinates, collect the coordinate reference system, datum, axis order and any local-grid explanation available. Also document the reference used for elevations. A plausible pair of numbers does not establish a location. Where the reference is unknown, preserve that uncertainty and identify the person or source most likely to resolve it.
Avoid converting values during informal preparation unless the transformation is documented and checked. Keep original values available for comparison. The migration mapping should show both the intended destination representation and any conversion applied, allowing a reviewer to distinguish a deliberate change from an accidental discrepancy.
6. Gather templates and meaningful outputs
Collect representative logs, tables and reports that users depend on. Include the underlying template or configuration where available, not just a PDF showing the final appearance. Mark essential content such as sampling symbols, descriptions, depth scales, notes and client-specific fields. Clarify whether acceptance requires equivalent information or an exact visual reproduction.
Data migration and template recreation are related but different tasks. A transferred value may exist correctly in the destination yet remain absent from an unconfigured report. Conversely, a familiar-looking log may conceal missing structured fields. Plan to review both the underlying records and the outputs that staff use in their normal work.
7. Profile data quality without rewriting history
Inspect representative records for missing values, inconsistent terminology, duplicates and questionable intervals. Note unusually long descriptions, special characters, alternative date formats and numeric fields containing text. These examples help reveal mapping decisions that a clean demonstration project would miss. Keep findings linked to specific records so they can be reproduced.
Classify issues as source defects, unclear conventions or potential conversion difficulties. Do not quietly correct every historical inconsistency before anyone understands it. Some apparent errors may reflect legitimate exceptions. Agree who can authorize corrections, what evidence is required and how the original information will be retained alongside the decision.
8. Select a pilot that represents the archive
Choose a manageable set of projects spanning the main sources, versions and workflows. Include an ordinary project, a heavily customized one and a difficult historical example where those categories exist. The objective is coverage of meaningful differences, not simply selecting the largest database or a convenient number of records.
Write down why each example was selected. For instance, one project may test repeated identifiers, another an uncommon coordinate system and a third a critical reporting template. This makes gaps in coverage visible. If an entire data type is absent from the pilot, avoid treating pilot success as evidence that the omitted type will transfer correctly.
9. Assign responsibilities and review time
Name a data owner, technical reviewer and person responsible for system access. In a small organization, one individual may hold several roles, but the responsibilities still need to be clear. Identify who can interpret unfamiliar source fields, approve mapping choices and decide whether unresolved exceptions prevent use of the converted data.
Reserve time for customer review as part of the schedule. A migration can pause while a question about units or template behavior waits for the only person who understands it. Agree a practical response process and an escalation route. Fast conversion does not eliminate the need for timely decisions from the people who own the information.
10. Define acceptance before the pilot starts
Describe what evidence will demonstrate success. Useful checks include matching intended records, preserving relationships, confirming selected values and producing representative outputs. Establish how exclusions and exceptions will be documented. Avoid a vague requirement such as “everything must look right,” which gives neither the conversion team nor the reviewer a reproducible test.
Acceptance should also address normal use. Ask a designated user to find an investigation, inspect the required records and produce a relevant deliverable in the destination environment. Record training or configuration needs separately from data discrepancies. Both matter, but they may require different corrective actions and different owners.
Assemble a concise readiness package
Your preparation package should contain a source inventory, representative files, important outputs, known conventions, issue list and pilot objectives. Include the intended destination products and versions, required timing and any file-handling constraints. Keep the package focused enough that a reviewer can identify the main risks without searching through an unexplained archive.
Use a simple readiness decision: ready for assessment, ready with identified questions, or blocked by a specific missing prerequisite. A missing legacy password or unavailable database may be a genuine blocker. Minor inconsistencies may instead become pilot test cases. This distinction helps teams make progress without pretending that every uncertainty has been resolved.
Connect preparation to the appropriate GAEA route
GAEA’s Migration Center page describes supported migration routes and scoped assistance. Confirm suitability for the exact source, version and required outputs. The planned centralized Migration Center capabilities remain upcoming where unreleased; this checklist does not imply that every proposed workflow is currently automated or available.
Preparation provides value regardless of which supported route is selected. An organized inventory, protected baseline and clear acceptance plan make discussions more concrete and reduce repeated clarification. They also leave the organization with a better understanding of its technical information, including material that may remain in an archive rather than move immediately.
Ready to discuss your migration? Contact GAEA with a representative source package and a description of the workflow you need. Begin with enough evidence to assess the route, then agree the pilot and review process before expanding to production.