A gINT migration plan should begin with the work your organization needs to continue: producing dependable borehole logs, finding historical information, checking test results, and delivering consistent project outputs. Moving records into a new database is one part of that work. Preserving their meaning and making the new workflow usable are equally important.
For teams considering WinLoG and GaeaSynergy, a controlled migration can be organized around six deliverables: a source inventory, an agreed destination workflow, a mapping specification, a representative pilot, an acceptance record, and a rollout plan. Each deliverable answers a question that would otherwise surface during production.
1. Establish the authoritative source
Identify the gINT projects that belong in scope and distinguish active data from superseded exports, test copies, and incomplete archives. Preserve unchanged source copies before cleanup. Record where each project came from, when the copy was taken, who understands it, and which outputs provide a trusted comparison.
- Collect project databases, associated libraries, templates, code lists, and relevant configuration notes.
- Locate photos, scanned logs, laboratory reports, and other attachments stored outside the database.
- Identify custom fields, calculated values, unusual test types, and differences between project generations.
- Record known units, coordinate systems, elevation references, and missing-value conventions.
A count of database files is not an adequate inventory. Two similarly named projects can use different structures, while several files may be revisions of the same investigation. Resolve identity and ownership before combining records.
2. Define the future workflow before mapping fields
List the tasks the destination must support and demonstrate them with a small example. For WinLoG and GaeaSynergy, confirm the relevant product versions, modules, deployment arrangement, and supported import route with GAEA. Agree how users will create projects, enter or import data, review records, prepare logs, and share approved outputs.
This is also the time to decide what belongs in structured fields and what should remain as a linked source document. A historical note should not be forced into a numeric field simply because the destination has no equivalent text column. Record gaps explicitly and agree an acceptable treatment before transfer.
3. Write a mapping specification that explains meaning
For each source field, document the destination, data type, unit, transformation rule, and handling of missing or invalid values. Include the relationships between projects, locations, intervals, samples, and tests. If identifiers change, retain a cross-reference to the original identifiers.
Pay special attention to interval boundaries and measurements tied to a reference point. A depth below ground cannot be treated as an elevation without a known ground level and reference system. A qualified laboratory result cannot be reduced to an unqualified number without losing meaning. Preserve qualifiers, remarks, and evidence supporting any conversions.
- Keep source values available for audit and troubleshooting.
- Document code translations, including codes without a direct equivalent.
- Specify whether duplicate identifiers are errors, valid project-specific names, or records requiring review.
- Keep an exception register with an owner, decision, and resolution for each issue.
4. Rebuild essential outputs deliberately
Select the log types and reports that users actually need. Compare their content, symbols, scales, units, legends, and treatment of blank or qualified values. A template with a familiar appearance may still display a field differently or omit information that was previously generated by a custom expression.
Define which outputs must match closely and which can be improved as part of the move. Separating required continuity from optional redesign keeps the pilot focused. Retain approved source PDFs so reviewers can compare migrated outputs without relying on memory.
5. Run a pilot that includes difficult records
Use more than the cleanest project. Include representative historical structures, a larger project, and records containing custom fields or known quality issues. Apply the documented process from source preparation through final output, and record any manual steps. The pilot should demonstrate a repeatable method rather than a one-off successful import.
- Reconcile project, borehole, sample, interval, and test counts at each stage.
- Check representative values and units against the source, including limits and qualifiers.
- Review interval order, relationships, locations, attachments, and identifier cross-references.
- Compare essential logs and reports, then have intended users complete routine tasks.
- Explain every material difference before accepting the pilot.
Matching totals alone do not prove success: records can be attached to the wrong borehole while overall counts remain unchanged. Conversely, a documented consolidation or exclusion can legitimately change a count. Acceptance requires an explanation of what changed and why.
6. Control the production transition
Choose a cutover approach that fits active project delivery. Define a source freeze or a documented process for capturing changes made after the baseline. Assign responsibility for the final transfer, review, user access, training, and support. Keep the original archive accessible under an agreed retention arrangement.
Specify what would trigger a rollback and how work entered after cutover would be handled. A rollback plan is incomplete if it restores the old system but loses new work. After rollout, track recurring questions and corrections so the process improves for the next project batch.
Build a pilot acceptance sheet before conversion
A useful acceptance sheet identifies the source project, the destination project, the reviewer, and the checks that must pass. Include expected record totals, a list of representative boreholes, and the outputs that will be compared. For each check, record the result, evidence, exceptions, and final decision. This turns “the migration looks right” into a conclusion another person can review.
Separate blocking issues from accepted limitations. A test assigned to the wrong sample would normally prevent acceptance. A historical attachment that was already missing may be an accepted limitation if its absence is recorded and the intended use remains appropriate. Do not allow the migration process to make these judgments implicitly. The project owner should understand the consequences of each exception.
Work through a sample mapping decision
Consider a hypothetical gINT project containing separate fields for a sample identifier, sample top depth, sample bottom depth, laboratory result, and remarks. The destination mapping should preserve the sample relationship first, then define how each measurement and remark is represented. If two projects use the same sample identifier, the project context must remain part of the identity.
Now suppose one result is stored as text with a less-than qualifier and another uses a blank to mean not tested. Treating both fields as unrestricted numbers would create problems. The mapping needs to preserve the qualifier and distinguish the missing result from zero. The pilot should include those exact cases, with a reviewer checking both the stored record and the output generated from it.
Document any transformation in language that a geotechnical reviewer can understand. “Converted to destination type” is insufficient. A useful note explains the original representation, the rule used, the destination fields, and the information retained separately. If the receiving structure cannot represent the source meaning adequately, stop that part of the transfer and agree a supported alternative.
Choose a migration batch strategy
A single cutover may suit a small archive with consistent structure and limited ongoing editing. A staged approach may suit a larger collection with several generations of project design. Grouping projects by structure can reduce repeated mapping work, while grouping by operational team can make training and support easier. Select the approach based on actual dependencies rather than file count alone.
For staged work, define a stable process version for each batch. Record which mappings, templates, and review rules were used. If a later pilot reveals a mapping defect, that record helps identify which earlier projects need correction. Without it, a small change can trigger uncertainty across the whole migrated collection.
Avoid uncontrolled editing in both systems. If parallel operation is necessary, specify which system is authoritative for each project and how changes will be reconciled. A spreadsheet noting that a project has moved can help operational coordination, but it should be supported by a clear ownership rule and a documented final transfer of outstanding changes.
Make training part of acceptance
Ask a frequent user to complete a realistic task in the destination: locate a historical borehole, inspect a sample result, update an authorized record, and produce an agreed log. Observe where the user hesitates and whether they can recognize the difference between original information and a normalized field. These findings are useful even when every technical validation check passes.
Prepare short instructions around those tasks, using the organization’s actual terminology and approved examples. Include where to find source documents, how to report questionable records, and who can approve corrections. A migration is easier to sustain when staff understand the review process as well as the buttons used to import data.
Plan support after the first production batch
Set aside a review period after rollout to collect issues from real projects. Classify each issue as a mapping defect, source-data problem, template problem, or training question. This prevents unrelated symptoms from being treated as one general migration failure and helps the right person resolve them.
When a correction is needed, document whether it applies to one record or to a reusable rule. Apply broad changes through a controlled process and repeat the affected acceptance checks. Keep the original evidence and the correction history accessible so that future reviewers can understand why the destination differs from the initial import.
The final handover package should include the source inventory, mapping specification, approved templates, pilot results, batch history, unresolved exceptions, and operating instructions. Together, these materials allow the organization to explain and maintain its migration after the original project team has moved on.
Plan around confirmed capabilities
The GAEA Migration Center is planned to support future migration-related resources and workflows. Any unreleased capabilities remain upcoming. Confirm current availability, supported source structures, and project-specific requirements before relying on a particular conversion or automation step.
To discuss a migration, review GAEA’s data migration information and contact GAEA with a representative project description and required outputs. A clear inventory, a realistic pilot, and written acceptance criteria provide a stronger starting point than committing the entire archive to an untested transfer.