Protect the value of historical project data
Migrate borehole, well, geotechnical, environmental and project data without treating conversion as a simple file-copy exercise. GAEA supports built-in migration routes for selected legacy products and scoped assistance for databases, spreadsheets and structured files.
The correct route depends on the originating application, database structure, data volume, templates and quality of the source records.
Move individual projects or project lists into GaeaSynergy 6 using the applicable migration wizard, while resolving project identifiers and current database requirements.
Bring earlier WinLoG projects, logs, templates and supporting libraries forward using the migration tools appropriate to the installed version and license configuration.
Import selected gINT project databases, review source tables, map fields and create or select a WinLoG template suited to the imported records.
Assess Excel, CSV, XML and other structured sources, then define field mapping, transformations, exceptions and deliverables before conversion begins.
Not every source field, code, attachment or custom report has a direct destination. A representative assessment identifies these differences before schedule, pricing or automated-transfer expectations are established.
This matrix identifies the normal starting route. Exact coverage is confirmed from the source files and target GAEA modules.
| Source | Typical route | Potential target | Assessment focus |
|---|---|---|---|
| GaeaSynergy 4 or 5 | Built-in project migration | GaeaSynergy 6 | Project IDs, database version, users, templates and network configuration |
| WinLoG 4 or 5 | Legacy upgrade or import tools | WinLoG 6 / GaeaSynergy 6 | Logs, templates, lithology libraries, identifiers and custom content |
| gINT project database | Guided project import and field mapping | WinLoG / GaeaSynergy | Tables, fields, units, template structure, symbols and unmapped values |
| Excel or CSV | Configured import or scoped conversion | WinLoG, EDMS or GDMS | Column meaning, data types, controlled values, units and record relationships |
| XML and structured exchange files | Schema-aware import | Applicable GAEA module | Schema version, identifiers, required elements and unsupported extensions |
| Other databases or proprietary exports | Assessment and custom conversion scope | Agreed GAEA database or exchange format | Access method, schema documentation, data ownership, mappings and test criteria |
Each stage produces information that can be reviewed before the next stage proceeds.
Identify databases, projects, templates, attachments, coordinate systems, units, versions and record volumes.
Inspect representative records for missing fields, inconsistent codes, duplicates, invalid intervals and source-specific conventions.
Define source-to-target fields, unit conversions, controlled-value translations, identifiers and handling for unsupported content.
Convert a representative subset and review logs, tables, locations, laboratory data, attachments and report outputs.
Compare record counts, identifiers, depths, key values and documented exceptions between the source and converted data.
Complete the approved conversion, retain the migration records and support user acceptance and production deployment.
A technically successful import is not sufficient by itself. The converted information should be checked against agreed acceptance criteria and representative outputs.
Migration tools can transform and transfer data, but they cannot independently confirm the geological, geotechnical or environmental correctness of the original records.
The project owner should approve mappings, acceptance criteria, exceptions and representative converted outputs before the final dataset becomes the production record.
The exact deliverables depend on scope, but a defensible migration should leave more than a converted database.
Source fields, target fields, transformations, unit conversions, defaults and controlled-value translations.
Unsupported, missing, duplicate or ambiguous records requiring correction, acceptance or separate retention.
Record counts, key-value checks, test results and an explanation of material differences.
The approved target database, projects or exchange files prepared for the agreed GAEA workflow.
Configured WinLoG templates, descriptors, symbols or supporting libraries included in the migration scope.
The reviewed pilot, approved criteria, remaining limitations and production-release decision.
Built-in migration and import wizards are appropriate when the source version is supported, the data structure is understood and your team can review the converted output.
An assessment is recommended when the source is customized, poorly documented, very large, inconsistent or essential to regulatory and engineering records.
Answers to common questions raised during initial planning.
Not automatically in every case. Coverage depends on the source schema, custom fields, attachments, reporting conventions and the selected target modules. Representative files are reviewed before the scope is confirmed.
The migration should operate on controlled copies or exports. Original source data should be retained according to the organization’s records-management and backup requirements.
Selected legacy GAEA templates and libraries may have supported upgrade paths. Templates from unrelated products may require recreation or mapping because their layout and object models differ.
Checks can include record counts, identifier matching, key-field comparisons, interval and unit reviews, exception reporting and representative output comparisons. The acceptance plan should be agreed before full conversion.
Yes. A representative pilot is recommended for customized, high-volume or business-critical migrations because it exposes mapping and output differences before full conversion.
Timing depends on source accessibility, volume, customization, data quality, mapping decisions, correction requirements and review availability. An assessment is needed before a reliable schedule can be provided.
GaeaSynergy includes a guided gINT project import workflow. Custom schemas, unusual tables, attachments and report recreation should be evaluated using representative project files.
Provide representative source files, the originating software and version, approximate project and record counts, important outputs, target modules, required completion date and any security or regulatory constraints.
Review the applicable product capabilities and existing migration guidance before planning a pilot.
Send sample source files and describe the target workflow. GAEA can identify the migration route, material mapping questions, review requirements and appropriate next step.
GAEA Technologies develops and distributes geoscience and engineering solutions worldwide. Our solutions have been used for over 30 years by companies and organizations around the world.
© 2026 GAEA Technologies. All Rights Reserved.