Choosing borehole logging software starts with the work your organization needs to repeat reliably. A polished sample log is useful, but it does not show how a team handles inconsistent descriptions, historical projects, revised templates or a deadline involving hundreds of boreholes. This comparison gives you a practical way to evaluate WinLoG, gINT, LogPlot and QuickLog without assuming that every organization needs the same system.
GAEA develops WinLoG, so this is a vendor-authored evaluation guide. Product editions, licensing and supported formats can change. Confirm each requirement with the supplier and test your own representative data before making a purchase or migration decision.
Start with the workflow, not the feature list
Write down the route from field observations to the approved deliverable. Include who enters the data, who checks it, who changes the template and who issues the final report. A small firm producing occasional logs may prioritize an accessible layout workflow. A larger organization may need shared structured records, repeatable validation, controlled terminology and connections to other subsurface deliverables.
Separate essential requirements from preferences. Required units, sample identifiers, monitoring well construction details and client report formats can be decisive. A preferred font or a convenient toolbar is less important if the workflow loses the relationship between a sample and its recorded depth. Use the same checklist for every candidate.
WinLoG: evaluate the structured logging workflow
WinLoG is GAEA’s borehole logging application. Its current product information describes configurable templates, structured data and validation and quality-control capabilities. Evaluate how those functions fit your actual records rather than assuming that a configurable product automatically reproduces every legacy log.
A useful demonstration starts with one ordinary borehole and one awkward example. Ask to enter overlapping or incomplete intervals, distinguish missing values from zero and revise a descriptive term. Then check how the application exposes the issue and how the correction reaches the generated log. Confirm the required modules and deployment arrangements for shared workflows involving GaeaSynergy or other GAEA applications.
Where field collection matters, evaluate the current Field Assistant workflow separately from the desktop application. Check supported devices, offline operation, transfer procedures and which fields move between systems. Do not assume that every desktop function is available on a mobile device simply because the tools belong to the same product family.
gINT: distinguish existing use from future planning
gINT remains part of many organizations’ historical project records and reporting processes. Familiarity with an established library can have real operational value. However, a software comparison should also address the supplier’s lifecycle timetable, future support and the effort required to keep historical projects usable.
Seequent’s current gINT transition guidance describes a phased transition through 2028, with discontinued support from 2029. Check the latest timetable and your agreement directly with the vendor. An older claim that all gINT support ended in January 2026 should not be used as a planning assumption.
The practical question is how long your organization intends to rely on the existing environment and what evidence it needs before changing systems. Inventory project databases, libraries, reports, lookup lists and dependencies. A readable PDF archive is valuable, but it does not replace editable structured records if future reuse is required.
LogPlot: test log design and your required data path
RockWare presents LogPlot as a borehole and well-log plotting product with log-design tools. It is a relevant candidate when the central requirement is producing logs with a particular visual arrangement. Evaluate the current version against your own columns, symbols, page lengths and output requirements.
Run the complete data path during a pilot. Check how records enter the application, how repeated revisions are made and how the team identifies the current source. Ask about your exact import and export formats rather than treating the word “import” as evidence that every legacy field or report rule will transfer.
If several people will maintain logs, assess template distribution and review procedures. These are workflow questions to demonstrate, not reasons to assume a product is suitable or unsuitable from its marketing category alone.
QuickLog: evaluate the actual product and deliverables
The QuickLog supplier’s website describes logging tools and configurable log content. Include it in a shortlist where its current offering appears to match the organization’s reporting needs. Confirm the relevant product, license and support terms directly, because names and packages can cover different working arrangements.
Use the same representative boreholes and acceptance checklist applied to other candidates. Check sample and test records, groundwater observations, construction details, long descriptions, page breaks and revision behavior. A fast first demonstration is useful, but repeatability across a project is the more meaningful test.
Compare six things on evidence
First, compare data structure. Can the team distinguish borehole headers, material intervals, samples, tests and observations without forcing unrelated records into one description field? Second, compare output control. Can approved templates represent your actual requirements consistently?
Third, compare checking and review. Demonstrate how errors are identified, corrected and documented. Fourth, compare collaboration and deployment. Establish who can work where, how updates are distributed and what happens when a user is offline.
Fifth, compare migration and interchange. Record supported formats and limitations for the exact versions involved. Sixth, compare support and ownership cost. Include training, template development, administration, migration checks and ongoing maintenance as well as the license price. Obtain current quotations rather than relying on historical prices copied into comparison articles.
Run a pilot with pass or fail criteria
Select a small dataset containing an ordinary hole, a long hole, an incomplete record and a project with unusual reporting requirements. Preserve the source and document what is intentionally excluded. Give each candidate the same requirements and record any manual preparation needed before the demonstration.
A useful acceptance criterion is concrete: all sample identifiers remain associated with the correct depth intervals; the requested units appear on every output; missing groundwater observations remain visibly missing; and the approved template prints without clipped descriptions. “Looks good” is too ambiguous to support an implementation decision.
Measure elapsed effort for the complete cycle, including correction and reissue. A workflow that produces a first log quickly but requires extensive manual cleanup may not save time across the project. Have both a regular user and a reviewer participate, because their priorities often differ.
Make a decision the team can explain
Summarize each candidate’s demonstrated strengths, unresolved questions and required work. A product can be a good fit even when some template development is needed, provided that effort is understood and included in the plan. Avoid presenting uncertain migration work as a guaranteed automated conversion.
For organizations assessing GAEA, request a WinLoG demonstration using representative project requirements. For a broader transition plan, see gINT alternatives and migration planning. The best outcome is a workflow that preserves useful data, produces dependable deliverables and can be maintained by the people who will actually use it.