Every exploration program starts in Excel. It’s free, everyone knows how to use it, and for the first ten drill holes it works fine. Then drilling scales. Two geologists overwrite each other’s edits on a Monday. Someone discovers nine versions of collar_FINAL_v3_USE_THIS.xlsx. A senior geologist spends a year auditing data that came out of the database “wrong” — except the database was a spreadsheet, and there was no validation in the first place.
Excel is excellent at what Excel does. The more useful question is when drill hole data stops being a spreadsheet problem and becomes a database problem — and what changes when you cross that line.
What Excel is genuinely good at
Before the critique: Excel earns its place. For quick lookups across a few hundred rows, for one-geologist prototype projects, for sketching out a data structure before committing to it, for financial modeling on top of drill data, Excel is hard to beat. It’s everywhere, it opens instantly, it doesn’t require IT involvement, and every geologist alive has used it.
Most exploration programs should start in Excel. The mistake is staying there past the point where the spreadsheet has quietly stopped being a database and started being a liability.
Where Excel breaks for drill hole data
No concurrent editing without conflict
Two geologists open the same workbook from a shared drive. Both make edits. The second to save wins; the first geologist’s work disappears. SharePoint and OneDrive co-authoring help with the simultaneous-open problem, but they don’t solve the underlying issue — there’s no record-level locking, no merge logic, and no way to enforce that two people can’t be entering different lithology codes for the same depth interval.
The downstream symptom is universal: teams end up with “nine copies of the data and no one knows which is right.” Each copy is a defensive fork made by someone who didn’t trust the shared version. Reconstructing the canonical dataset becomes a forensic exercise.
No validation at entry
Excel will happily accept anything you type. A geologist enters BAS instead of BSLT for basalt. Another enters bslt in lowercase. A third enters basalt spelled out. By the end of a 200-hole program, the lithology column has eleven variations of the same rock. The same applies to units (g/t vs gpt vs ppm-as-grams), depth precision (some rows to two decimals, others to whole metres), and free-text comments where structured data should live.
Conditional formatting and data validation rules exist in Excel, but they live in the workbook. If someone copies a row, pastes from another sheet, or opens the file in a tool that doesn’t honor those rules, the constraints disappear. Validation needs to live with the data, not with the file.
No audit trail
Who changed the assay value at 142.3m, when, and why? In a spreadsheet, that information doesn’t exist unless someone manually logged it. Excel’s tracked-changes feature is fragile, often disabled, and not designed for the multi-user, long-horizon use case that drill data requires.
For JORC, NI 43-101, and SAMREC reporting, that history isn’t optional. Auditors expect to see when a record was created, when it was modified, by whom, and what the previous value was. Reconstructing that from a stack of dated spreadsheet copies — when it’s possible at all — is a real project.
No referential integrity
A proper database enforces that the lithology code you enter has to exist in the lithology lookup table. Excel doesn’t. Lookup tables become suggestions; codes drift between geologists; assay results get entered against sample IDs that don’t appear in the sample table. The data looks fine cell-by-cell, but the relationships that make it analyzable are broken.
This problem doesn’t surface during logging. It surfaces six months later when someone tries to build a resource model and the modeling software refuses to join the tables because the keys don’t match.
No depth-interval logic
Excel doesn’t understand drill holes. It doesn’t know that Depth From should always be less than Depth To. It doesn’t know that intervals in the same hole shouldn’t overlap. It doesn’t know that a survey shot at 100m has to fall between the collar and the total depth. None of that logic is enforceable without writing custom VBA, which means it isn’t enforced in practice.
These are the errors that propagate into Leapfrog as silently-wrong models. The hole renders, the surfaces compute, and the geologist trusts the output — even though two intervals are double-counted because someone typoed Depth From = 145 instead of Depth From = 154.
No real export pipeline
Getting drill data from Excel into Leapfrog, ArcGIS, Datamine, or Vulcan cleanly means manually reformatting every time. Column names have to match exactly. Coordinate systems have to align. Numeric columns can’t have stray text. Date formats have to be consistent. The reformatting step is where errors get introduced — and where geologists end up spending hours of their week that have nothing to do with geology.
The deeper problem: every export is a one-off. There’s no persistent workflow, no saved field mapping, no validation that the output matches the destination schema. The next geologist re-invents the process from scratch.
The real cost of “Excel works fine”
Teams that have moved off spreadsheets tend to tell the same story: nobody noticed Excel was costing them anything until they measured the cost.
One project geologist documented spending a full year auditing data that had come out of a spreadsheet-and-MX-Deposit hybrid system. A junior mining company cited six-figure costs to clean up legacy spreadsheet data before a resource update. Six-week verification cycles get compressed to under a week once validation lives at the point of entry. The $100k+ cleanup cost for Excel-driven projects stops sounding like an outlier once you’ve heard it a few times.
The reframe is uncomfortable but accurate: you pay for a database one way or another. Either upfront — in licensing, setup, and a learning curve — or downstream, in audit time, rework, missed deadlines, and the resource-estimation errors that come from data you didn’t trust. Most teams discover, retrospectively, that the upfront cost would have been smaller.
What a geological database actually does differently
A geological database does a handful of things a spreadsheet simply can’t — and all of them matter for drill hole data specifically.
Validation lives with the data, not the file. Lithology codes have to come from a defined list. Depth From must be less than Depth To. Required fields can’t be left blank. Errors surface during logging, when the geologist who made the mistake is still in the core shed — not six months later when someone is building a resource model and the data won’t join.
There’s one copy of the data. Every user works against the same live database. Two geologists logging different holes write to the same store; two geologists logging the same hole are forced to resolve the conflict at entry, not in a merge afterward. Referential integrity means you can’t enter an assay against a sample ID that doesn’t exist in the sample table — the relationships between tables stay intact regardless of which workstation entered the data.
The database understands what a drill hole is. Overlapping intervals get flagged. Inverted intervals get blocked. A survey shot logged outside the hole length gets caught. That depth logic doesn’t exist in a spreadsheet without writing custom VBA — and VBA constraints disappear the moment someone pastes data from another sheet.
Every change is timestamped and attributed. For JORC, NI 43-101, and SAMREC compliance, that history isn’t optional. Export to Leapfrog or ArcGIS is a configured workflow, not a manual reformat — once set up, it runs the same way every time.
None of this is exotic. It’s the baseline definition of a database. Drill hole data is multi-user, multi-table, validation-heavy, and compliance-relevant — exactly the use case databases are designed for.
Choosing your first geological database
A short checklist for teams making this transition:
- Concurrent multi-user without conflict — test this for real. Have two people edit simultaneously and watch what happens.
- Validation at entry, not after. Errors caught at the keyboard cost seconds to fix; the same error caught in a resource model costs weeks.
- Direct export to your modeling stack. Leapfrog, ArcGIS, Datamine — whichever you actually use. The export workflow should be configurable and reproducible, not a manual reformat each time.
- Full data export with no lock-in. If you cancel the subscription, you should be able to take a complete copy of your database in a portable format.
- Setup that doesn’t require a database administrator. If your evaluation requires a week of consultant time before the first hole goes in, the platform is working against your team size.
- Fit for the team you actually have. Enterprise platforms exist and are often overkill; tools designed for small-to-mid exploration teams exist too.
Broadly, the category splits three ways:
- Access-based or local SQL Server tools (GeoSpark, GeoBase) — affordable, real databases, but limited cloud capability and concurrent-edit handling.
- On-premises enterprise platforms (acQuire GIM Suite, Datamine Fusion) — deep governance and configuration capabilities, designed for major mining companies with IT teams.
- Cloud-native SaaS (MX Deposit, Blue Butterfly, 1point) — browser-based, real-time sync, lower setup friction, but pricing and integration breadth vary widely.
The 2026 comparison of core logging platforms covers the specific tradeoffs for each named product.
A practical migration path from Excel
Five steps that consistently work for teams making this transition:
1. Audit your current spreadsheets and document the implicit schema. Before you import anything, write down what columns exist, what the data types are, what’s allowed, and what the lookup values are supposed to be. You’ll find inconsistencies — that’s the point. Document them now.
2. Define your data structure in the new platform. Use the schema you just documented to set up tables, columns, dropdown lookups, validation rules, and depth-interval relationships. This is where you collapse the eleven spellings of basalt back into one.
3. Clean the data before import, not after. It’s tempting to “just import everything and clean it up later.” Don’t. Once messy data is in the new system, it looks legitimate, and cleanup becomes invisible work. Run a cleanup pass on the spreadsheets first — normalize codes, fix obvious errors, resolve duplicates.
4. Import in batches and validate. Start with one or two holes. Confirm the import produced exactly what you expected — collar coordinates intact, depth intervals aligned, lookup values matched. Then expand. A bad import done all at once is harder to diagnose than a bad batch of three holes.
5. Lock the old spreadsheets to read-only. The single biggest migration failure mode is letting people keep editing the old spreadsheets “just in case.” They will, and the canonical store immediately splits in two again. Make the spreadsheets read-only the day the new database goes live, and route everyone through the new system.
Excel is a tool. So is a database. The reason this migration is worth making isn’t that spreadsheets are wrong — it’s that drill data outgrows them, and the cost of staying past that point compounds quietly until it’s a six-figure cleanup project.
Blue Butterfly was built as the database that small-to-mid exploration teams reach for when they hit that wall — browser-based, validation at entry, real-time cloud sync with offline fallback, no specialist setup, and full SQL export of your data at any time. If your team is past the spreadsheet breaking point, it’s the kind of tool worth a look.