Engineering and architecture
Moving from gINT to OpenGround: what happens to your borehole history
By SourceX Editorial · Updated
Short answer
In a gINT to OpenGround migration, project data such as boreholes, samples, strata and lab tests can be mapped into OpenGround, but report templates, lookup lists and custom calculations usually need rebuilding. Borehole history survives only if you also keep a read-only archive of every legacy project file, library and issued log, so past logs stay reproducible.
Key takeaways
- Data moves through mapping; presentation and calculation logic in gINT libraries usually has to be rebuilt.
- Inventory every gINT library in use before mapping, because offices often run different versions.
- Test the mapping on your oldest and most complex projects, not only recent ones.
- Keep a read-only archive of project files, libraries and issued PDFs before turning gINT off.
- A migrated, searchable archive is easier to reuse, present in a sale or license than files on old servers.
What happens to borehole history when you leave gINT?#
Borehole history survives a move to OpenGround only if you treat it as three separate things: the data, the way it was presented and the logic that produced it. The data, meaning projects, locations, samples, descriptions and test results, can be mapped into OpenGround's structure. The presentation and logic live in gINT library files and templates, and those rarely carry over intact.
That split matters because an issued boring log is a professional document. If a client, a court or a future project asks how a log looked and how a value was derived, the firm needs to reproduce it, not just show the underlying numbers in a new system.
What maps directly and what needs work#
Standard project and test data maps most directly, while anything the firm customized in its gINT library needs deliberate mapping or rebuilding. Use the table to sort your estate before choosing tools or a cutover date.
| Item | Typical migration path | Main risk |
|---|---|---|
| Project and location records | Field-to-field mapping into OpenGround headings | Coordinate systems and datums recorded inconsistently |
| Samples, strata and soil descriptions | Mapping, with lookup values aligned | Abbreviations and description codes that differ by office |
| Laboratory test results | Mapping to test groups and headings | Custom test tables with no direct equivalent |
| Custom tables and fields | Template mapping or new headings | Fields dropped silently during import |
| Lookup lists and abbreviations | Rebuild in the new configuration | Old codes that no longer expand to full text |
| Log, fence and report templates | Rebuild or redesign | New outputs that do not match issued logs |
| Calculated fields and expressions | Re-create and verify | Values that change because the logic differs |
| Scanned logs, photos and attachments | Move separately and link by location | Links broken when file paths change |
Inventory the gINT estate before mapping anything#
The gINT estate is usually larger and less uniform than IT expects, because offices and senior geologists adapt libraries over the years. An inventory up front tells you how many mappings you need and which projects carry the most risk.
Expect surprises. Project files saved in personal folders, libraries copied and renamed for a single client, and logs edited after issue are all common, and each one changes how the migration should be planned.
- Locate every project database, including those on laptops, old servers and archived drives.
- List each library in use, its version and the projects that depend on it.
- Note custom tables, fields and expressions added to each library.
- Record the coordinate systems and units each office uses.
- Match project files to project numbers in the accounting system so each has a client and date.
- Identify scanned or paper logs that never entered gINT.
- Flag projects under a litigation hold or with client restrictions.
Build the mapping once and test it on hard projects#
A mapping should be built once per library family and tested on the projects most likely to break it: the oldest library still in use, the project with the most custom lab testing and a project from each office. Recent, clean projects tell you little.
Reconcile each test project field by field, then generate a log in OpenGround and compare it with the issued PDF alongside a senior engineer. Differences in presentation can matter as much as differences in data, because the issued log is what clients and contractors relied on.
| Check | How to run it | Passes when |
|---|---|---|
| Record counts | Count locations, samples and tests before and after | Counts match for every project |
| Depths and elevations | Compare values for a sample of locations | No changes beyond agreed rounding rules |
| Descriptions | Compare full text for a sample of strata | Codes expand to the same wording |
| Lab results | Compare each test type on the test projects | Values and units match the source |
| Issued output | Compare new logs with issued PDFs | A senior engineer accepts any differences |
Keep a read-only archive of legacy projects#
A read-only archive of legacy gINT projects is the safeguard that makes the migration reversible in practice. Freeze copies of every project database, the exact library each one used, the data templates and the issued PDFs, and record the gINT version that produced them.
Store the archive by project number with access controls, and record file hashes so you can show later that nothing changed. Where your licensing allows, keep a working gINT installation that can open the archive, and consider exporting key projects to an open exchange format such as AGS or DIGGS for long-term readability.
Document where the archive lives and who may grant access to it, so it is not lost when the people who built it move on.
Common migration mistakes#
The most common migration mistakes come from treating the move as a software upgrade rather than a records project.
- Migrating only active projects and leaving the rest on servers no one maintains.
- Editing or overwriting a shared library while the migration is under way.
- Mixing units or coordinate systems across offices without recording them.
- Accepting imported data without checking it against issued logs.
- Letting gINT licenses lapse before the archive has been verified.
- Skipping sign-off by a licensed engineer on the new log templates.
Illustrative: a geotechnical firm moves its log archive#
Illustrative: a fictional geotechnical firm with several offices decides to move from gINT to OpenGround. Each office has adapted its own library, older projects sit on a retired file server, and logs from before gINT exist only as scans.
The data manager inventories the estate and finds three library families. The firm builds one mapping per family, tests each on its oldest and most complex projects, and has a senior engineer approve the new log templates against issued PDFs. Active and recent projects are migrated; older projects go into a read-only archive with their libraries, issued logs and a working gINT installation.
After cutover, engineers query new and recent work in OpenGround and pull legacy issued logs from the archive. When a client later asks for data from an older project, the data manager migrates that single project on demand using the tested mapping.
Your archive after migration, and how SourceX looks at it#
A migrated, well-documented borehole archive is easier to use for proposals and desktop studies, easier to present in a sale and easier to assess for licensing. Under the SourceX Enterprise Data Value Framework, structured and linked records rate better on data cleanliness and AI utility, and preparation cost falls when the mapping work is already done.
SourceX assesses archives through the SourceX five-step transaction, starting with metadata such as systems, years and record types; no files are shared during the initial assessment. Rights still come first, because migrating data does not change what client contracts allow.
Frequently asked questions
Can OpenGround open gINT files directly?
Import support depends on versions and on how your libraries were built. Check Bentley's current documentation for supported import routes, then test with your own projects, including the oldest and most customized ones, before committing to a cutover plan.
Do we need to migrate every historical project?
No. Many firms migrate active and recent projects, archive the rest read-only with their libraries and issued logs, and migrate older projects on demand. What matters is that every project can still be opened and reproduced when someone needs it.
Are AGS or DIGGS exports worth producing?
They can be. Open exchange formats keep data readable without proprietary software and are often requested by clients or agencies. Check that an export carries every field you rely on, because exchange formats may not hold firm-specific custom fields.
Who should sign off the migration?
A senior licensed geotechnical engineer should approve the new templates and the reconciliation results, with the data manager signing off on completeness. Issued logs are professional documents, so reproducing them is an engineering question as well as an IT one.
Does moving to a cloud platform change who owns the data?
Migration does not change ownership; your client contracts and your agreement with the software vendor do. Read the vendor's terms on hosting, data use and export before cutover, and confirm how you would retrieve your data if you later leave the platform.
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.