Carrying years of thickness readings into a system that was not built for them
A thickness history module for an NDT service provider must keep every reading a technician ever recorded, not just the current minimum, and keep with it the date, the technician and their certification status on that date, the instrument and its calibration state, the method and probe, and, for any reading excluded from a corrosion rate, the recorded reason it was excluded.
Service providers sit in an unusual position: they generate the data but do not own it. The nominal thickness, the retirement thickness and the corrosion allowance come from the client's engineering files, and the client's OSHA 29 CFR 1910.119(j)(4)(iv) record obligation is discharged with the provider's report. That makes provenance, not storage, the hard part of a migration. A legacy datalogger export typically carries a CML label, a value and a timestamp, plus five characters of technician initials if you are lucky. It does not carry the probe type, the velocity setting, the surface temperature, or the fact that on 14 March the operator could not get a back wall echo on three points and typed the nominal instead. Those omissions are invisible until someone recomputes a corrosion rate from the migrated set and gets a different answer than the report the client already signed.
Source: Written against OSHA 29 CFR 1910.119(j)(4) mechanical integrity documentation requirements; ASME BPVC Section V, Article 23 (SE-797) for measuring thickness by the manual ultrasonic pulse-echo contact method; API 510, API 570 and API 653 for corrosion rate calculation and inspection record practice; ASNT SNT-TC-1A and ISO 9712 for personnel certification records.
| Legacy field as exported | What it actually encodes | What the new system must store | Failure mode if it is dropped |
|---|---|---|---|
| TECH = 'RJM' | One of three technicians who used those initials across nine years | Person record with SNT-TC-1A or ISO 9712 level and certification validity on the reading date | A client audit asks who took a 2019 reading and the answer is a guess |
| THK = 0.000 | No back wall echo obtained, not zero remaining wall | Null value plus an exclusion reason code and a free-text note | The rate engine sees total wall loss and escalates a CML that was never measured |
| DATE = 03/04/2021 | March or April, depending on which office produced the export | ISO 8601 date with the originating locale retained on the record | Readings reorder, the short-term interval inverts and the rate returns negative |
| CML = 'N-1' | Nozzle 1 on some vessel belonging to one of forty different clients | Client, site, unit, circuit, equipment and point as one compound key | Two clients' histories merge and neither corrosion rate is defensible |
| NOM = 0.375 in | Nominal at original construction, superseded when the spool was replaced in 2018 | Nominal with an effective-from date and the document it was taken from | Long-term rate is computed across a replacement and reports metal gain |
| One value per CML | The minimum of a nine-point grid; the grid itself was discarded | Every point in the grid with its position, or an explicit grid-minimum flag | Localised pitting cannot be told apart from general thinning on re-survey |
Why a service provider's thickness history is a custody problem, not a storage problem
An owner-user's integrity department keeps thickness history for equipment it owns. A service provider keeps it for equipment it will never own, on behalf of clients who each number their CMLs differently, set their own retirement thicknesses, and hold their own view of when a reading is valid. The same technician may shoot a hydrotreater circuit for one client on Monday and a storage tank chime for another on Wednesday, under two different written practices and two different data formats.
That changes what keeping the history means. The provider is not maintaining one dataset; it is maintaining forty datasets that happen to share a workforce and a set of instruments. Anything that lets one client's data influence another's, whether a shared CML label, a global default nominal or a site-wide unit setting, is a defect rather than a convenience. It is also the thing most legacy tools got wrong, because they were designed for a single owner-user and then pressed into service by a contractor.
The commercial consequence is specific. When a contract ends, the client is entitled to a complete, readable copy of everything recorded on their assets, and the provider has to produce it without exporting anyone else's readings alongside. A history that cannot be sliced cleanly by client is a history that creates a disclosure problem the first time an account turns over.
The five fields OSHA already requires, and the four more a corrosion rate needs
OSHA 29 CFR 1910.119(j)(4)(iv) is unusually concrete about documentation. Each inspection and test performed on process equipment must record the date, the name of the person who performed it, the identifier of the equipment, a description of the inspection or test, and the result. For a covered process those five fields are not a best practice; they are the minimum the client's mechanical integrity programme is audited against, and the provider's report is what discharges them.
A corrosion rate needs four more. It needs the instrument and its calibration state on the day, because a gauge found out of tolerance at its next verification casts doubt backwards over every reading since the last good check. It needs the method and probe, because a single-element contact reading, a dual-element reading, an EMAT reading and a profile radiograph are not interchangeable at the thousandth of an inch. It needs the surface temperature, because an uncorrected hot reading is systematically wrong. And it needs the velocity or material setting actually in use.
Those four are precisely the fields a datalogger export leaves out, because the instrument knows them and assumes the operator does too. A migration that maps only the OSHA five is technically compliant and analytically useless: you can prove a reading was taken and you cannot prove what it means.
Exclusions: the field legacy systems never had
Every real thickness dataset contains readings that should not feed a corrosion rate. A point shot through a weld cap. A reading taken before a spool was replaced. A value recorded when the operator could not hold a back wall echo and entered the nominal to close out the survey. A CML whose label was transposed with its neighbour. These are normal. They are not misconduct; they are the ordinary texture of field work under a permit with a clock running.
The failure is not that they exist. It is that legacy systems record an exclusion as a deleted row, or as a flag with no reason attached, so the judgement evaporates. Two years later nobody can say whether a point was excluded because the metal was replaced or because the couplant failed, and those two reasons have opposite implications. One legitimately resets the baseline. The other means the point was never measured and the trend has a hole in it that the arithmetic will happily paper over.
The design that survives an audit stores the reading, stores the exclusion, stores a reason code drawn from a controlled list, stores free text, stores who excluded it and when, and recomputes rates with the excluded points visibly absent rather than silently gone. A client's corrosion specialist should be able to reinstate a point and watch the rate change, because that is the argument they will have to make in a review meeting.
What actually breaks during a migration
The dominant failure is date interpretation. A dataset assembled from offices with different locale settings will contain both readings of 03/04/2021, and nothing in the file distinguishes them. Readings reorder, intervals invert, and the short-term corrosion rate comes out negative for a subset of CMLs. That looks like a curiosity in a data quality report and is in fact a silent corruption of every downstream number.
The second is units and rounding. Millimetres recorded to two decimals carry 0.01 mm of resolution, about 0.0004 in; inches recorded to three carry 0.001 in. Convert one into the other and back and you introduce drift that a long-term rate absorbs and a short-term rate does not. The third is nominal thickness. Legacy rows usually carry a single nominal per CML with no effective date, so a 2018 spool replacement leaves the pre-replacement rows quoting the new nominal, and the long-term rate reads as metal gain.
The fourth is grid collapse. Many older tools stored only the minimum of a scan or a grid. Once the individual points are gone you cannot distinguish a 0.030 in pit from 0.030 in of general thinning on the next survey, and those two demand entirely different responses. Migration cannot recover what was discarded, but the new system must at least record that a historical value is a grid minimum rather than a point reading, so the trend is interpreted for what it is.
Reconciling migrated history against reports the client has already accepted
A migration is not finished when the rows load. It is finished when a recomputed corrosion rate matches the number on a report the client signed. That reconciliation is the only test that exercises the whole chain at once: field mapping, unit handling, date ordering, exclusion logic and rate formula. Row counts and load success rates prove nothing about any of them.
Run it on a stratified sample rather than everything: the highest-consequence circuits, the CMLs with the shortest remaining life, the ones that changed contractor mid-history, and a random tail. Every mismatch is diagnostic. A rate that differs by a rounding step points at units. A rate that differs by an order of magnitude points at date ordering or at a 0.000 masquerading as a measurement. A rate that inverts points at the nominal or at an unrecorded replacement.
Keep the reconciliation as a permanent record, not a project artefact that dies with the implementation folder. When a client's auditor asks why the number in the system differs from the number in a 2019 PDF, the answer needs to be a dated reconciliation with a named reviewer, not a recollection of what the data team found during cutover.
Multi-client segregation, handover and exit
Segregation has to be structural rather than presentational. The identity of a CML is the compound of client, site, unit, circuit, equipment and point, never the point label alone. Nominal thicknesses, retirement thicknesses, unit systems, rate formulas, exclusion vocabularies and report templates all belong to the client, because they came from the client's engineering documents and they are the client's to change.
Handover is the other half of the same design. Every client relationship ends eventually, and the exit obligation is usually written into the inspection contract: a complete copy of all data generated on their assets, in a readable format, within a defined period. That is a routine export when the model is segregated and close to impossible when client is a column somebody sometimes filled in.
The same structure earns its keep long before exit. It is what lets you give a client read-only visibility of their own trend without exposing your other accounts, and what lets you answer a due-diligence question about data handling with a description of the model rather than an assurance about intentions.
Where the history has to connect on both sides
Thickness history is not a standalone archive. On the provider's side it connects to the job: the work order that authorised the survey, the technician's certification record and its expiry date, the instrument's calibration certificate and next-due date, and the report that went out. If any of those live in a separate spreadsheet, the provenance chain has a break in it exactly where an auditor will pull.
On the client's side the data usually has to flow into their own inspection data management system, in their field names, their units and their file format, on their schedule. That connection is where providers quietly lose margin. Re-keying a survey into a client's system, or reformatting a deliverable per client per campaign, is unbilled labour that scales with the size of the account. A per-client export configuration turns a recurring manual task into a one-time setup task.
It also closes the quality loop. If the client's system rejects a file, the rejection should land against the survey in your system with the offending rows identified, so the technician corrects the point on the next visit rather than the office correcting a spreadsheet and nobody learning anything.
How to evaluate a vendor's migration claim
Ask for a dry run on your worst dataset, not your cleanest. The useful test set is the one with a contractor change in the middle, a spool replacement, mixed units, ambiguous dates and at least one year of 0.000 entries. A vendor who asks for your tidiest export is testing their loader rather than your problem, and the result will tell you nothing about the day you go live.
Ask what the system does with a field it cannot map. Silent dropping is the wrong answer, and so is refusing the entire file. The right behaviour is to load the row, park the unmapped content in a retained raw payload attached to the reading, and raise it for disposition, because two years later that unmapped column turns out to have been the probe type or the surface temperature.
Finally, ask to see an exclusion audit trail and a reconciliation report from a previous migration, with client identifiers removed. Those two documents say more about whether the vendor has actually done this before than any feature list. If you want to run that test on a sample of your own history, contact info@atlantisndt.com for a demonstration and a scoped migration review.
What has to migrate besides the thickness value and the date?
The technician and their certification status on the reading date, the instrument and whether its calibration was valid then, the method and probe used, the surface temperature, the velocity or material setting, and the client's nominal and retirement thickness with the document they came from. OSHA 29 CFR 1910.119(j)(4)(iv) already requires the first group for covered processes; the rest is what makes the reading recomputable years later.
How should readings excluded from a corrosion rate be carried across?
As retained rows, never as deletions. Each exclusion needs a reason code from a controlled list, free text, the person who applied it and the date. The distinction that matters is between an exclusion that legitimately resets a baseline, such as a spool replacement, and one that means the point was never truly measured, such as a lost back wall echo. Those two look identical once the reason is gone.
Our legacy system kept only the minimum reading per CML. Is that recoverable?
No. Discarded grid points cannot be reconstructed from a stored minimum. What the new system can do is record explicitly that the historical value is a grid or scan minimum rather than a point reading, so the trend is read correctly and the first new survey establishes a proper point set. Comparing a future point reading against a historical grid minimum without that flag produces a false apparent gain in wall thickness.
How do we keep dozens of clients' histories separate in one system?
By making the client part of the identity of every record rather than a filter applied afterwards. A CML is identified by client, site, unit, circuit, equipment and point together, because labels like N-1 and TML-4 recur in every plant on earth. Nominal thicknesses, unit systems, rate formulas, exclusion vocabularies and report templates belong to the client record, not to a global default that one careless edit changes for everyone.
What proves a migrated reading is the same reading the client already accepted?
A reconciliation. Recompute the corrosion rate from the migrated data and compare it against the figure on a report the client signed. Run it on the highest-consequence circuits, the shortest remaining lives, the CMLs that changed contractor mid-history, and a random tail. Retain the result as a dated record with a named reviewer, because that is what answers an auditor who finds a discrepancy against an old PDF.
How long does thickness history have to be kept?
For the life of the equipment, in practice. API 510, API 570 and API 653 all rely on records reaching back to installation to establish a long-term corrosion rate, and an owner-user under OSHA process safety management must be able to produce inspection documentation on demand. A service provider is the custodian rather than the owner, so retention periods and handover obligations usually appear in the inspection contract as well.
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.