gINT migration
Move your gINT archive into a validated database.
gINT reaches end-of-life on 31 December 2028. G& takes gINT projects, libraries, log templates and companion workbooks into one central geotechnical database — validated on entry, accepted by a named engineer, and ready to emit AGS 4.1 submissions.
- EOL date
- 31 Dec 2028
- Target format
- AGS 4.1
- Validation layers
- 4
- Mapping profiles
- 1 per vintage
The migration path
A controlled sequence, not a bulk import. Each stage is auditable and reversible until acceptance.
01
Inventory the archive
Catalogue every gINT project, library, template and companion workbook, and record which AGS version each one emits.
02
Map once per vintage
Build a mapping profile for each archive vintage: depth datums, units, location IDs, stratum codes, test naming.
03
Validate on entry
Run integrity, engineering-logic, AGS 4.1 and plausibility checks. Quarantine anything orphaned or contradictory.
04
Accept with provenance
A named engineer accepts each batch. Source file, standard version and mapping profile are recorded against every value.
05
Operate and deliver
New works run in G&; the migrated corpus feeds logs, factual report tables and AGS 4.1 packages from approved records.
Where gINT migrations usually fail
Templates, not just data
Most stalled migrations fail on log layouts and library rules, not on borehole records. Both are in scope from day one.
Silent unit drift
Historic archives mix units and datums between vintages. Mapping profiles normalise them explicitly instead of by convention.
Orphaned lab results
Lab results without a resolvable sample reference are quarantined for engineering judgement, never guessed into place.
No audit trail
Every migrated value keeps its source file and acceptance record, so a submission remains defensible years later.
Where each stage lives in G&
Platform
Central database & four-layer validation
The capture, govern, validate, approve and deliver line that migrated records enter.
Platform overview →
Modules
Legacy intake, laboratory and governance
The modules that handle archive intake, lab lifecycle, submission control and approvals.
Browse modules →
Handwriting OCR
Paper logs that never reached gINT
Scanned field and lab sheets transcribed into validated records in the same corpus.
See OCR →
Outputs
What the migrated corpus produces
Anonymised borehole logs, factual report tables and AGS 4.1 packages built from approved records.
View outputs →
Readiness
39-point AGS 4.1 checklist
Check the archive against the same criteria a submission is judged on before you migrate.
Run the check →
Resources
Migration path & checklist downloads
Supporting material for planning a legacy migration ahead of end-of-life.
Open resources →
gINT migration questions
+What is happening to gINT?
gINT is scheduled for end-of-life on 31 December 2028. After that date the desktop application is no longer supported, so projects held only in gINT libraries and .gpj files need a documented migration path before the archive becomes read-only in practice.
+What gINT data can be migrated?
Borehole and trial pit records, depth intervals, stratum descriptions, in-situ tests such as SPT and CPT, groundwater observations, laboratory results, plus the library templates and log formats used to produce them. Excel workbooks and previously exported AGS files that sit alongside the gINT archive are taken in the same pass.
+Do I lose the old logs and report formats?
No. Log layouts are rebuilt as G& output templates, and the original files are retained as provenance against every migrated record, so a historic log can still be reproduced and defended.
+How is migrated data validated?
Migrated records pass the same four validation layers as live data: data integrity, engineering logic, AGS 4.1 compliance and plausibility. Orphaned or ambiguous results are quarantined rather than imported on trust, and a named engineer accepts each batch into the corpus.
+How long does a gINT migration take?
Effort scales with the number of archive vintages, not the number of boreholes. A mapping profile is built once per vintage and then applied across every project that shares it, so large archives with consistent templates migrate quickly.
+Can we run both systems during the transition?
Yes. New works can start in G& while the legacy archive is migrated in the background. Once accepted, the archive is queryable by stratum, formation, test type or depth interval alongside current projects.
Start the migration while the archive is still fully supported.
We inventory your gINT projects and templates, agree mapping profiles per vintage, and migrate under validation with a named engineer accepting each batch.