Carrying decades of mining thickness readings into a system that can defend them
In mining and minerals, thickness history is a wear record, not a corrosion-rate record. Migrating it means carrying every reading with its date, technician, instrument and method, plus the spool rotations, replacements and re-routes that legitimately reset a baseline, and every excluded reading with the reason it was excluded. Drop those events and the imported trend is arithmetically wrong from its first day.
A mine's thickness file is dominated by assets no pressure code governs: slurry lines, launders, cyclone feed, transfer chutes, thickener and leach tank walls, mill discharge. Loss there is erosion and abrasion, directional, concentrated at bends and downstream of injection points, and proportional to tonnage and solids fraction rather than to elapsed time. Alongside them sit a handful of genuinely coded items: a pressure oxidation autoclave to ASME Section VIII, an acid plant vessel, a steam header. One database must hold both populations without pretending they follow the same rules. Migration is where that distinction is usually lost, because legacy systems flattened everything into a single reading table with a single rate field. Carry the asset's governing basis, the CML identity through every renumbering, and the events, rotation, replacement, re-route, relining, that reset a baseline. Without them the new system inherits confident numbers with no defensible provenance.
Source: Written against API 574 for thickness measurement location practice, API 570 and API 510 for the coded pressure equipment inside a concentrator or acid plant, ASME B31.3, ASME Section VIII Division 1, ASTM A106/A530 permissible wall under-tolerance for seamless pipe, ASTM E797 for manual pulse-echo contact thickness measurement, MSHA 30 CFR Parts 56 and 57 for surface and underground metal and non-metal mines, and the records and knowledge-base provisions of the Global Industry Standard on Tailings Management.
| Legacy artefact being migrated | What a straight import does to it | What must move with the reading |
|---|---|---|
| A CML numbered 06 on a slurry line renumbered twice since 2009 | Creates three unrelated CMLs, or merges three unrelated locations into one | A CML identity chain: every prior identifier, the date it changed, and the reason |
| A spool rotated 120 degrees at 40 percent wear | Trend continues across the rotation and computes a negative wear rate | A rotation event with date, angle, and a trend break so pre- and post-rotation series stay separate |
| A replaced spool entered as a normal reading | Regression sees wall thickness increase and reports centuries of remaining life | A baseline reset event carrying new material, schedule, heat or MTR reference and install date |
| A stored remaining-life figure with no raw readings behind it | Imports a computed answer whose inputs can never be re-derived | The raw readings, the nominal used, its source, and the rate method in force at the time |
| A reading flagged bad and hidden in the legacy screen | Silently dropped, so the record cannot explain why a survey has a gap | The reading, a null-or-suspect status, the exclusion reason code, and who reviewed it |
| A contractor PDF survey that never entered the legacy database at all | Ignored, leaving a multi-year hole nobody notices until an interval is challenged | The document, its readings transcribed and reconciled, and a provenance flag marking transcription |
Mining thickness history is a wear record, and wear does not run on a calendar
The default assumption inside most inspection databases is that metal loss is roughly linear in time, so two readings and a date difference give a corrosion rate in mils per year. In a refinery that assumption survives contact with reality often enough to be useful. In a concentrator it does not. The loss on a cyclone feed line, a mill discharge launder or a tailings spool is erosion and sliding abrasion, and it tracks throughput, solids fraction, particle size distribution and slurry velocity. A line that sat idle for eight months while the pit was re-sequenced lost almost nothing during those months, and a line that ran through a hard ore campaign at elevated tonnage lost far more per month than its long-term average implies.
This has a direct consequence for what the history has to store. A reading with a date is not enough to derive a defensible rate. The record needs to be able to carry, or at least reference, the service context between readings: campaign, ore type, throughput, whether the line was in service at all. Systems that model only date and value force the integrity engineer back into a private spreadsheet to normalise rates against tonnage, which recreates exactly the fragmentation the migration was supposed to end.
It also changes what a good reading looks like. Wear in slurry service is directional. The wall is intact at twelve o'clock and gone at five o'clock on the outside of a bend. A single reading per CML is close to meaningless; the record has to hold the full clock-position grid as a set, with the minimum identified but every position retained. Legacy systems that stored only the governing minimum have already destroyed most of the information you are trying to migrate, and that loss is not recoverable after the fact.
The five events a migration usually drops
Rotation is the first. Mines rotate slurry spools 90 or 120 degrees at a defined wear threshold to move fresh metal into the wear path. The CML tag stays on the spool and the physical grid underneath it turns. Every reading before the rotation and every reading after describe different metal. A trend across that boundary is not merely imprecise, it is inverted: the system sees wall thickness increase and reports a negative wear rate, which most software silently clamps to zero and converts into an unlimited remaining life.
Replacement is the second, and it fails the same way. A spool changed out during a shutdown resets to new wall. If the post-replacement reading lands in the same series as the pre-replacement readings, the regression sees a step increase. Re-route is the third: a line diverted around a new thickener has different geometry, different velocity and a partly new CML set, and the surviving old spools carry their history with them into a new line number. Relining is the fourth, where rubber, ceramic tile or HDPE is renewed and the parent wall behind it becomes accessible or inaccessible depending on the lining method.
The fifth is a change of ownership or contractor. Mine sites change hands, and with them change inspection contractors, survey conventions, grid schemes and databases. The 2011 readings may be in a vendor's proprietary system, the 2016 readings in an asset management module, and the 2021 readings in a folder of PDFs. Each of those transitions is an event in its own right, because the convention for what a reading meant may have changed at that boundary. A migration that treats all three sources as one flat table inherits three incompatible conventions and no way to tell them apart.
What the legacy export actually contains, and what it quietly computed
Open the export before designing the load. The common surprise is that the columns you assumed were measurements are derived. Many legacy systems store a computed remaining life, a computed rate, or a percentage-of-nominal figure alongside, or instead of, the raw value. Those derived columns were produced by a rule that may have been changed several times since, and by a nominal that may have been assumed from a schedule table rather than measured at installation. Importing them puts a permanent, unverifiable number into the new system's most authoritative field.
The nominal is worth dwelling on because it is where the largest silent error usually lives. Seamless pipe supplied to ASTM A106 with the general requirements of ASTM A530 may legitimately arrive up to 12.5 percent below nominal wall. On NPS 6 Schedule 40, nominal 0.280 inch, an as-supplied wall of 0.245 inch is fully compliant and has lost nothing. A legacy system that assumed 0.280 inch has already booked 0.035 inch of phantom loss into the record. Migrated forward, that phantom loss inflates every rate computed against an original-thickness baseline and understates every remaining life.
Units are the second surprise. Mining sites are frequently mixed-unit environments, with imperial pipe schedules, metric instruments and a legacy database storing four decimal places that the gauge never produced. Fabricated precision is not harmless; it survives into charts and interval justifications where it reads as certainty. The load should preserve the value as recorded, record the unit as recorded, note the instrument resolution, and refuse to invent digits during conversion.
Exclusions: the readings a legacy system was built to throw away
Most legacy thickness modules treat a suspect reading as an error to be corrected. The technician re-shoots, the new value replaces the old, and the original disappears. That behaviour is exactly wrong for an auditable record, and it is particularly damaging in mining because the conditions that produce a suspect reading are chronic rather than exceptional: scale on the outside of a leach tank, a rubber lining that the probe cannot see through to the parent wall, a magnetite skin, an internal ceramic tile that returns a false back-wall echo, a surface too rough for reliable coupling.
A defensible history records the reading and its disposition separately. The value may be null, suspect or superseded, but the attempt is retained with a reason code, the technician who took it, the instrument, the method and technique, and the person who accepted the exclusion. That structure answers the question that gets asked years later, when an interval is challenged: was this location not measured, or measured and rejected? Those are different failures with different corrective actions, and a record that cannot distinguish them cannot support either one.
During migration the practical difficulty is that the exclusion reason was usually never stored in a field. It exists in a comment column, a scanned survey sheet, or a contractor's cover letter. The realistic approach is to load what exists with an explicit provenance flag stating that the reason was reconstructed from a free-text note rather than captured at source, so the new record is honest about the confidence of its own history. Fabricating a tidy reason code where none existed is worse than admitting the gap.
Coded and non-coded assets living in the same database
A gold or copper operation with a pressure oxidation circuit runs autoclaves that are ASME Section VIII Division 1 vessels, often brick-lined with an acid-resistant membrane, alongside sulphuric acid plant equipment, oxygen and steam headers, and hundreds of kilometres of piping that no pressure code touches. The coded assets are managed under an owner-user inspection programme with formal intervals and documented calculations; the wear assets are managed to an internal standard where the trigger is a wear threshold rather than a code minimum thickness.
One thickness history has to serve both without homogenising them. The autoclave shell needs a minimum required thickness derived from a design calculation, a documented basis, and both long-term and short-term rate treatment. The slurry line needs a wear-limit trigger, a rotation and replacement plan, and rates normalised to throughput. If the software offers only one model, someone will force the wear assets into a pressure-equipment schema and the resulting remaining-life numbers will be quietly meaningless, or force the coded assets into a wear schema and lose the calculation basis that justifies the interval.
The migration must therefore carry a governing-basis attribute at asset level and preserve, for the coded population, the actual minimum required thickness and where it came from. A number typed into a field with no reference behind it is the single most common finding when a mine's fixed-equipment programme is reviewed, and a migration is the moment when that reference is either recovered or lost permanently.
Rebuilding a baseline you can defend after the move
After loading, the first job is not reporting. It is reconciliation. Take a representative set of CMLs across each asset class and rebuild their entire history by hand from source documents, then compare that reconstruction to what the new system holds. Look for series that changed length, minimums that moved, dates that shifted from survey date to report date, and rates that changed sign. The differences you find are not import defects to be patched one by one; they are symptoms of a mapping rule that is wrong everywhere it was applied.
Second, mark confidence explicitly. Not all migrated history is equally trustworthy, and pretending otherwise is how a migration destroys credibility. A reading transcribed from a scanned survey sheet, a reading whose CML identity was inferred, a reading whose nominal was assumed, and a reading loaded cleanly from a structured export are four different grades of evidence. Store the grade. It costs one column and it is the difference between an engineer trusting the system and quietly maintaining a shadow spreadsheet.
Third, do not backfill. The temptation during migration is to smooth the record: interpolate a missing survey, average a rotated series, assign a plausible nominal. Every one of those actions creates a number with no source that will later be cited as measured. Leave the gaps visible and let the next survey close them. A history with honest holes is defensible. A history with invented continuity is not, and the invention is undetectable once the migration project team disperses.
How to evaluate a system on migration rather than on demo data
Demonstrations run on clean synthetic data where every CML has an unbroken series and every reading has a nominal. That environment cannot reveal whether the product can hold your actual record. Insist on loading a real extract, including your worst asset: the re-routed slurry line with three generations of CML numbering, two rotations, one spool replacement and a two-year gap where the contractor's PDFs were never transcribed. What the system does with that asset is the whole evaluation.
Ask specific questions with observable answers. Can a reading be stored with a null value and a mandatory exclusion reason? Can the same CML hold two different trend segments separated by a rotation event, with the rate computed only within a segment? Can the record show the instrument serial number and its calibration status as at the reading date, not as at today? Can a superseded reading be retrieved with its original value, the replacement value, the reason and both users? Can the legacy source record be retained verbatim alongside the normalised record, so provenance survives the transformation?
Finally, ask what happens on the day a nominal is discovered to be wrong. In a good system, correcting a nominal is an event that recomputes derived values forward and leaves a record of both states. In a poor one it silently rewrites twenty years of computed history with no trace. That single behaviour tells you more about whether a product can carry a mining record than any feature list. Atlantis builds inspection management on this model, and a scoping consultation on your own extract is available on request at info@atlantisndt.com.
What breaks first when mining thickness history is loaded from a legacy system?
CML identity. Mines renumber measurement locations after every re-route, spool swap and line extension, and legacy systems usually overwrite the old number rather than keep a chain. The import then splits one location into three short series or fuses three locations into one long false one. Before loading anything, reconcile identifiers across every generation of numbering and store the chain, not just the current label.
How does a spool rotation corrupt a migrated wear trend?
Slurry spools are rotated to redistribute wear, so the point that was six o'clock becomes two o'clock. The physical grid moves under the CML label. A trend line drawn across the rotation compares a worn position to a fresh one and returns wall gain, a negative wear rate, and an inflated remaining life. The migration must carry a rotation event with its date and angle so the series breaks at the correct point.
Should excluded readings be migrated or left behind?
Migrated, always, with the reason attached. An exclusion is evidence about measurement conditions: coupling lost through scale, probe on a wear liner rather than the parent wall, wrong spool after a rotation, instrument later found out of calibration. Left behind, the record shows an unexplained gap in a survey and nobody can tell whether the reading was never taken or was taken and discarded. Those two situations have very different consequences.
Does a mine need API 570 records for slurry piping?
Usually not by law. Slurry lines, launders and chutes are generally non-jurisdictional wear assets managed to the owner's internal integrity standard, while MSHA 30 CFR Parts 56 and 57 govern the workplace rather than prescribing a piping inspection regime. Coded items such as an autoclave or an acid plant vessel are different. The database must record which basis governs each asset, because it determines how the interval was justified.
How do you migrate a system that stored remaining life instead of raw readings?
Treat the stored figure as an artefact, not an answer. Load the raw readings where they exist and mark assets where only the computed value survives, because that number cannot be re-derived and should not be trended forward. If the legacy nominal was assumed rather than measured, the imported loss may include mill under-tolerance: ASTM A106/A530 permits seamless wall up to 12.5 percent below nominal before any metal is lost at all.
Is API 510, 570 or 653 inspector training part of this offer?
No. Those inspector certifications are administered by API and Atlantis does not deliver or issue them. Atlantis provides NDT method training to ASNT SNT-TC-1A and ISO 9712 across UT, RT, MT, PT, ET, VT, PAUT and TOFD, ASNT Level III consulting, inspection management and reporting software, digital twins, 3D laser scanning and independent report validation. Ask for a consultation to scope a migration.
Built for any business that runs on operations
Most companies do not fail at their craft. They lose time, margin and goodwill in the gaps between the tools they use to run the place — a quoting spreadsheet that does not talk to the job sheet, a job sheet that does not reach accounts, and a compliance folder nobody can search when a client asks. Atlantis closes those gaps by putting the whole operation on one platform, so information is entered once and everything downstream stays in step.
What you can run on it
- Sales and CRM — leads, quotes, follow-ups and the pipeline that tells you what next month looks like.
- Projects and job costing — plan the work, track the hours and materials against it, and see the margin while the job is still live rather than at final account.
- Field and service teams — dispatch, schedules, mobile capture that works with no signal, and sign-off from site.
- Inventory and purchasing — stock, suppliers, reorder points and goods receipt, joined to the jobs that consume them.
- People — records, qualifications and licences with renewal reminders, timesheets, leave and payroll.
- Quality and documents — procedures and forms under revision control, with the audit trail an inspection or accreditation body actually asks for.
- Accounts — invoicing, expenses, multi-currency and the reporting your accountant stops chasing you for.
Affordable, accessible, fully customizable — and we mean each word
Affordable because the whole suite is included rather than sold to you a module at a time, and because implementation is done by people who have run operations rather than by a chain of subcontractors. Accessible because it runs in a browser and on a phone, works for a small team on day one, and does not need a specialist on staff to keep it alive. Fully customizable because your process is the thing that makes you competitive — the software should bend to it, not the other way round.
Industries we configure for
Service businesses and contractors, manufacturing and fabrication, trading and distribution, laboratories and testing houses, engineering consultancies, construction and facilities, and asset owners across energy, marine, aerospace and infrastructure. Inspection and testing is where we started, and it remains the sector we go deepest in — but the platform underneath is general-purpose, and most of what it does has nothing to do with inspection at all.
What happens when you get in touch
A short conversation, not a sales sequence. We ask how the business runs today and where it hurts, show you the platform doing that work, and send a written quote shaped to your region, your team size and the scope you actually need. No obligation, nothing to install first, and no pressure to decide on the call. Reach out and tell us what you are trying to fix.
Related: business management platform · inspection management software · choosing the right category of software · modules · by industry · asset integrity platform. Book a free consultation.