Choosing a gINT alternative involves more than finding software that can draw a similar borehole log. Organizations often have years of project databases, report definitions, symbols, terminology and working practices tied to their existing environment. A successful transition preserves the information that matters and gives the team a repeatable way to produce and review future deliverables.
This guide explains how to shortlist alternatives, plan a representative pilot and separate demonstrated capabilities from planned developments. GAEA develops WinLoG and GaeaSynergy, so the discussion is vendor-authored. Confirm current product specifications, licensing and migration arrangements directly with each supplier.
Check the current gINT lifecycle timetable
Start with the vendor’s published information rather than a date repeated in an old article. Seequent’s gINT transition guidance describes a phased transition through 2028, with discontinued support from 2029. Your agreement and the current vendor timetable should guide operational planning.
A support transition is a reason to assess dependencies and establish a tested path. It does not by itself prove that an existing project is corrupt or unusable. The immediate task is to understand which projects can still be opened, what software and libraries they require and what records the organization needs to retain for future work.
Assign an owner to maintain the inventory and decisions. Without ownership, migration tends to become a collection of isolated exports whose relationship to the original projects is difficult to reconstruct later.
Decide what you are replacing
Separate log production from data management, field collection, collaboration and interpretation. Some organizations primarily need a dependable replacement for a reporting workflow. Others want to reorganize how subsurface records are shared and reused across projects. Those are different implementation scopes.
Write a short requirements statement using real examples. For instance, the team may need to retain sample identifiers, depth intervals, units, groundwater observation times and construction details while producing an approved client log. Include what must remain editable and what only needs a readable archive. A requirement stated this way is easier to test than “migrate everything.”
Also identify activities that should stay outside the first phase. Historical cleanup, new terminology and redesigned templates can be valuable, but changing everything at once makes it harder to determine why an output differs from its source.
Consider OpenGround for the vendor’s transition route
Seequent identifies OpenGround as its cloud-based geotechnical information management platform and its transition destination for gINT users. Organizations should evaluate that route against their needs for collaboration, data organization and report production, using the vendor’s current migration guidance.
A common supplier does not eliminate the need to validate project-specific content. Ask how your databases, libraries, custom reports and lookup values will be handled. Determine which items transfer, which require mapping or rebuilding and which remain as archived references. Include account administration and operating procedures in the evaluation.
Consider WinLoG and GaeaSynergy for a GAEA workflow
WinLoG provides a structured borehole logging workflow with configurable templates and current validation and quality-control capabilities. Where broader project workflows are needed, assess how the relevant GAEA applications and GaeaSynergy configuration support the required work.
Use a demonstration to establish the exact data path for your source material. Ask the GAEA team to identify supported formats, necessary preparation, mapping decisions and any manual work. A claim that data can be imported is not the same as evidence that every custom gINT report, field or lookup value will reproduce automatically.
GAEA’s Migration Center capabilities discussed in related Knowledge Center articles are planned or upcoming unless explicitly confirmed as released in current product documentation. Do not make a migration schedule depend on an unreleased automated conversion, assessment or checking capability. Base the first pilot on the tools and services available for the agreed project today.
Consider focused logging tools where the scope is narrower
Products such as LogPlot and QuickLog may belong on a shortlist when the principal requirement is log production. Their suitability depends on the actual data, templates and operating arrangements involved.
Evaluate focused tools with the same acceptance criteria used for a broader platform. Confirm current formats, deployment options, support and licensing directly. Avoid ranking a product solely by the appearance of an example log or by a feature matrix that has not been checked against the current version.
Inventory the source before exporting
Record each project’s identifier, location, owner, file type, date range and known dependencies. Preserve a protected source copy. Include the libraries, symbols and reference materials needed to understand the records, not just the files that happen to contain the borehole rows.
Identify missing values, duplicate identifiers, unusual units, inconsistent terminology and depth intervals requiring review. Record these conditions before conversion so the team can distinguish an existing source issue from a migration error. Preserve the original value alongside an approved normalized value where traceability requires it.
Do not turn missing data into zero, guessed coordinates or a convenient default soil description. An incomplete historical record can remain useful when its limitations are explicit. Invented completeness is much harder for a later reviewer to detect.
Create a mapping and exception record
For each important source field, identify its destination, units, transformation rule and acceptance check. Header coordinates and elevations need reference-system information. Samples need their original identifiers and depth relationships. Groundwater observations need their dates, times and measurement context wherever those are available.
Keep an exception list for fields that cannot transfer directly. State whether each will be retained in an attachment, represented in another field, reviewed manually or excluded with approval. This makes the migration decision visible and prevents unexplained information loss from being disguised as a successful import.
Validate a representative pilot
Choose projects that expose variation: an ordinary site, an older dataset, a long borehole and a project with custom reporting. Compare source and destination record counts, identifiers, intervals and units. Then inspect the generated deliverables against approved reference outputs.
Counts are necessary but insufficient. A project can contain the expected number of rows while attaching a test to the wrong sample or displaying the wrong units. Include selected record-level checks and a professional review of output meaning. Document differences that are intentional separately from defects requiring correction.
Agree on acceptance criteria before the pilot starts. Specify who signs off, what unresolved issues prevent progression and where the evidence will be stored. Test that a second team member can repeat the documented process; a successful one-person demonstration is not yet an operational migration procedure.
Plan rollout and ongoing access
Once the pilot passes, group projects into manageable batches and define a cutover process for active work. Train users on both the new workflow and the handling of exceptions. Retain the source archive and a record of the mapping and software versions used.
Measure the complete cost: preparation, conversion, template work, checking, training, administration and ongoing operation. Compare that with the expected benefit using realistic internal effort estimates. Avoid promising savings based only on the speed of one import or one generated log.
For a broader selection checklist, see our borehole logging software comparison. To evaluate a GAEA path, bring representative project files and reporting requirements to a demonstration. A defensible choice is one whose limitations are understood and whose results your team has actually checked.