A geotechnical archive can look secure while becoming progressively harder to use. Project databases still exist, finished borehole logs are stored as PDFs, and an experienced team member knows where to find the original files. Yet none of those conditions guarantees that the information can be moved reliably into another system. Legacy geotechnical data migration becomes risky when access, meaning, and relationships depend on undocumented assumptions.
The problem is rarely just the age of a file. It is the growing distance between the people and tools that created the record and the people who will need to interpret it next. Organizations can reduce that risk by treating migration readiness as part of data management, before a replacement platform or urgent project forces the issue.
A backup preserves files; migration preserves usability
Backups are essential, but a successful restore does not prove that a dataset is understandable. A restored database may rely on a particular software version, a local library, custom report expressions, or attachments saved outside the project folder. A PDF may preserve the appearance of a log without preserving the fields needed for filtering, analysis, or reuse.
A useful readiness test is to ask a colleague who did not create the project to reconstruct one borehole. Can they identify its location and reference system, reproduce key intervals and results, locate supporting documents, and explain the codes? Every unanswered question identifies work that should happen before migration.
Five ways migration risk accumulates
- Access becomes dependent on a single working computer, application configuration, or person.
- Custom fields and classification codes remain undocumented, so similar labels can carry different meanings across projects.
- Attachments become separated from their records as folders are reorganized or network paths change.
- Repeated exports create competing copies without a clear authoritative source or revision history.
- Units, coordinate systems, elevation references, and missing-value conventions are assumed rather than recorded.
These issues interact. A missing attachment may be recoverable when its creator remembers the filename. An unfamiliar code may be explainable while a project geologist is available. Once that knowledge is lost, a technical conversion can still produce a complete-looking database while leaving significant uncertainty about its contents.
The hidden cost is interpretation
Consider a hypothetical archive with three fields named depth, water, and result. Depth might mean the top of a sample, the bottom of an interval, or the total drilled depth. Water might be a measured depth below ground, an elevation, or a descriptive note. Result might hold a number, a qualified value, or a code. Moving these columns is straightforward; deciding what each value means requires evidence.
Historical records should not be made artificially precise during cleanup. If a coordinate reference system is unknown, record that uncertainty and investigate it. If a unit is inferred from a report, retain the basis for the inference. Preserve the source value alongside any normalized value so a reviewer can follow the transformation.
Assess archives by consequence and recoverability
A practical assessment does not require an elaborate scoring system. Start with the datasets most likely to support active work, recurring clients, regional interpretation, or future investigations. Then consider how difficult they would be to recover if the current application or specialist were unavailable.
- Business use: Which projects are consulted frequently, and what decisions depend on them?
- Access: Can the source be opened and exported using a documented process?
- Meaning: Are fields, codes, units, and reference systems defined?
- Completeness: Are linked records and attachments present and traceable?
- Verification: Are there trusted logs or reports against which migrated results can be checked?
Prioritize high-value datasets with fragile access or poorly documented meaning. A small, complex archive can deserve attention before a much larger collection with consistent structure and good documentation.
Reduce risk before selecting a migration route
Create a source inventory and preserve an unchanged baseline. Collect databases, code libraries, report templates, supporting files, and representative outputs together with a short explanation of their relationships. Record application versions where known and identify a person responsible for resolving questions. Keep archival copies separate from working cleanup copies.
Next, select a representative pilot. Include a clean project and at least one with custom fields, unusual tests, multiple units, or incomplete records. Document mapping decisions and expected exceptions before loading the destination. Compare both record-level data and outputs that engineers actually use. A visually familiar log is useful evidence, but it is not a substitute for checking values and relationships.
Recognize the operational warning signs
Migration risk becomes easier to manage when the organization can recognize it in everyday work. Staff repeatedly asking who has the working copy, manually retyping historical logs, or postponing an archive search because the old application is inconvenient are useful warning signs. These activities reveal friction that a file inventory alone may miss. Ask users to describe the last project where historical information was difficult to retrieve, and follow that example back to its source.
Another warning sign is a growing dependence on finished reports as substitutes for underlying data. A report may be exactly what a client needed at issue, but it may omit intermediate observations, sample relationships, or values excluded by its layout. If the organization increasingly relies on those reports because the database is difficult to access, migration planning should account for both the surviving structured records and the information visible only in documents.
Use a hypothetical project to expose the dependencies
Imagine a consulting team returning to an industrial site investigated fifteen years earlier. It finds issued logs, a project database, and a folder of laboratory PDFs. Several boreholes use a local coordinate grid, some sample numbers were reused in a later phase, and the report template pulls descriptions from a separate library. The files are present, but their relationships are not fully documented.
The team first preserves the collection unchanged. It then identifies which investigation phase each record belongs to, compares selected database records with issued logs, and records the missing grid definition as an unresolved question. Laboratory reports are linked using project and sample context rather than sample number alone. The template library is copied into the archive package with a note explaining its role.
This example illustrates why migration scope should be established before bulk conversion. The work is partly technical, but it also requires decisions about evidence and meaning. A converter cannot safely decide that two sample numbers represent the same sample or that a local coordinate can be treated as a national grid position. Those decisions need a documented basis and a responsible reviewer.
Turn the assessment into a manageable work programme
Divide the archive into groups that share a structure, source application, or business purpose. For each group, record its owner, priority, known dependencies, and a sample project suitable for testing. This makes it possible to learn from a pilot and apply the result to similar projects without assuming that every file in the organization behaves the same way.
Estimate effort in terms of discovery, mapping, conversion, verification, and user transition. Keep those activities visible when discussing a migration budget. A collection with consistent fields may be quick to convert but expensive to review if supporting evidence is scattered. Conversely, a complex project with good documentation may be easier to migrate reliably than a simple database whose conventions are unknown.
Assign separate responsibilities for source knowledge, technical transfer, and acceptance. One person may perform more than one role, but the responsibilities should remain explicit. Technical completion means that the process ran as intended. Acceptance means that the resulting information is fit for the agreed uses, with limitations recorded and understood.
Decide what to retain, normalize, and defer
Not every historical inconsistency must be corrected before migration. Distinguish issues that prevent safe transfer from improvements that can follow it. A missing relationship between samples and locations may block acceptance; inconsistent capitalization in descriptive notes may not. Agree these priorities before cleanup begins so teams spend their effort on the information that most affects reliability.
Preserve original values when introducing standardized fields. For example, a normalized material category can support searching while the original description remains available for interpretation. Maintain a decision log for transformations and a queue for records that need specialist review. This approach makes progress possible without disguising uncertainty or allowing an endless cleanup exercise to delay all migration work.
Measure readiness through evidence
Track a small set of useful measures: priority projects with confirmed ownership, sources that can be opened through a documented procedure, records with known reference systems, attachments with working links, and pilot exceptions resolved or accepted. These measures show whether uncertainty is shrinking. The number of files copied is useful for transfer control, but it says little about whether the archive is becoming easier to understand.
Review readiness again after staff changes, archive reorganizations, or a significant change in software workflow. Migration risk is not eliminated by writing a plan once. A maintained inventory, a reproducible access procedure, and a modest set of tested projects give the organization a practical foundation for future decisions.
Where the planned GAEA Migration Center fits
The GAEA Migration Center is planned as a future resource for migration-related workflows and guidance. Unreleased capabilities should be treated as upcoming, with availability and supported source formats confirmed before they are included in a project plan. Organizations can prepare now by documenting their archives and defining acceptance criteria.
For a discussion of current options, visit GAEA’s data migration information or contact GAEA with a description of your source systems, project volume, and required outputs.
A practical first step
Choose one archive that matters to your organization and produce a short migration-readiness record: where the authoritative source lives, what is required to open it, what its fields mean, what is missing, and how a converted copy will be checked. Repeat that process across priority projects. The result is a clearer scope for migration and fewer decisions left to guesswork when the move begins.