Import the Evidence, Recompute the Date: Migration for Fab Shops

A fabrication shop's interval problem is not the one the software was built for

Interval and remaining-life software is designed around in-service degradation: measure wall loss, compute a rate, halve the remaining life, cap it at the code maximum, publish a date. A fabrication shop's core output has none of that. A vessel leaving the shop with a U stamp has full nominal thickness, full corrosion allowance and no operating history. Applied to new construction, the arithmetic has nothing to work on.

This is why fab shops are frequently sold the wrong product and then conclude, reasonably, that the category does not apply to them. The category does apply — it just applies to different assets. The shop's own pressure plant carries jurisdictional obligations: air receivers, steam headers, hydrotest systems, blast pots. Overhead cranes and below-the-hook devices carry periodic inspection requirements under ASME B30.2, and slings and rigging under B30.9 with OSHA 29 CFR 1910.184. NDT equipment carries verification intervals — densitometer and step wedge checks under ASME Section V Article 2, ultrasonic system linearity, magnetic particle field indicators. Personnel carry annual vision examinations and recertification cycles under the shop's SNT-TC-1A written practice.

And there is a third population that most shops underestimate. A shop holding an R stamp under NBIC NB-23, or performing field repairs on in-service equipment, inherits the owner-user's obligations at the interface. The repair has to be evidenced to a standard that will satisfy an API 510, 570 or 653 inspector working for the owner, and where the repair is based on a fitness-for-service assessment under API 579-1/ASME FFS-1, the assumptions in that assessment determine when the equipment must next be examined. Those dates are real, they are contractual, and they are usually tracked nowhere.

What is actually in the legacy system

Ask a shop what it is migrating from and the answer is usually a name — a homegrown Access database, an early QMS module, a Windows share with a folder structure that has survived three IT refreshes. What matters is not the name but the shape of the records inside it, and that shape is remarkably consistent across shops that have been operating for two decades.

There will be job-numbered spreadsheets containing thickness data, some of which record remaining wall and some of which record metal loss, with no field distinguishing the two because the convention was obvious to whoever built the sheet. There will be a date column labelled next due, populated by planners and carried forward year on year with occasional adjustment. There will be radiographic film in envelopes indexed by job number, with the weld location marked on a hand-drawn shooting sketch that exists only on paper. There will be welder qualification records that carefully document what was actually done during the test — the plate thickness used, the position welded — rather than the range that qualification confers under ASME Section IX. There will be heat numbers as free text, transcribed by hand, in at least four formats.

None of this is negligence. Every one of these choices was efficient for the system it was made in, where the people who understood the conventions were in the building and could be asked. What breaks is the transfer. A convention that lives in institutional memory does not survive an import, and the migration's first real task is to make the implicit rules explicit before anything is moved.

Import the evidence, not the answers

The single decision that determines whether a migration produces a working system or a laundered mess is what happens to the legacy due dates. The tempting path is to import them: the column exists, it is populated, it maps cleanly, and the project looks finished a month earlier. The consequence is that every error accumulated over fifteen years arrives in the new system with a pristine provenance chain attesting that the data came from the system of record. It is now harder to challenge than it was before.

The alternative is to import evidence and recompute. Readings with dates, points, instruments and technicians. Nominal thickness and required minimum thickness with the basis for each. Calibration as-found and as-left values. Welder qualification essential-variable ranges, derived from the recorded actuals by applying the code's rules explicitly and recording that this is what was done. Repair and alteration records with the design basis. From that evidence the engine derives every date itself, using the applicable rule, and records which rule it used.

Then it reconciles. For every asset, the recomputed date sits beside the legacy date with the difference and the reason. This report is the actual deliverable of the migration. In practice it splits into three groups: a large number of small differences that reflect rounding and anchoring conventions and can be accepted wholesale; a moderate group where the legacy date was conservative and the recomputed date is later, which needs review but is not urgent; and a small group where the legacy date was later than the code permits. That last group is typically a handful of items, and it is the reason the exercise was worth doing.

The datum break: how a migration manufactures corrosion rates

Thickness history is only a series if the thing being measured did not change. A plate replacement, a weld overlay, a section renewal, a re-rate to a different MAWP, or a change in the location where readings are taken all break the baseline. Import a decade of readings without recording those events and the engine will compute a long-term rate straight across the break, comparing post-repair thickness to pre-repair thickness.

The output is either an enormous rate — if the repair thinned the nominal — or, far more often, a negative one, because a new plate is thicker than the old one it replaced. Negative rates get clamped to zero or discarded, remaining life becomes effectively unbounded, and the asset drops to the bottom of every priority list it should be near the top of. The failure is silent, and it looks like good news.

API 510's requirement to consider both short-term and long-term corrosion rates and to use the more conservative result exists partly to surface exactly this kind of inconsistency. A migration that carries baseline events across as first-class records — with a date, a type and a scope — lets the engine segment the series correctly and compute rates within each segment. A migration that treats readings as a flat list cannot do it, and no amount of later data cleansing will reconstruct which readings belonged to which datum, because the information was never in the spreadsheet to begin with.

Single readings, estimated rates, and being honest about provenance

A large share of any legacy estate has exactly one thickness reading, taken when someone finally got access to the asset, and nothing before or after it. No rate is computable from one point. The engine has to do something, and what it does reveals how seriously the product takes evidence.

The wrong behaviour is to substitute a default rate silently and present the resulting date exactly as it presents a date derived from ten years of measurements. Both appear in the same column, in the same font, with the same apparent authority. The right behaviour is to apply an estimated rate — from similar service in the same shop, from a corrosion specialist's judgment, or from the design corrosion allowance divided by design life — and to carry a rate provenance field that says which of those it was.

Provenance then becomes an operational tool rather than metadata. Assets whose dates rest on estimated rates are the ones whose dates are least defensible, so they go to the front of the queue for a second reading. After one cycle the population of estimated-rate assets should have visibly shrunk, and that shrinkage is a better measure of programme maturity than any completion percentage. A system that cannot report how many of its dates rest on assumption is not reporting the thing that matters most about itself.

Welder and procedure continuity is an interval problem too

Fabrication shops rarely think of welder continuity as belonging in the same system as inspection intervals, which is why it is so often the thing that fails an audit. ASME Section IX's continuity provisions under QW-322 and the corresponding AWS D1.1 requirements both work on elapsed time since a welder last used a process. The clock runs quietly, it runs per welder per process, and nothing announces its expiry.

Structurally this is identical to any other recurring obligation: an entity, a rule, an elapsed-time trigger and an evidence requirement. The reason spreadsheets fail at it is not conceptual difficulty but volume and cross-product. Forty welders across five processes is two hundred independent clocks, each needing a record of last use, and the record of last use lives in production data that the QC spreadsheet has no connection to. The lapse is discovered when a customer's source inspector asks for a continuity log during a shop visit, at which point production stops.

The same applies to welding procedure qualification records and to the mapping between a WPS, the PQR supporting it and the welders qualified within its ranges. This is where the migration point about essential variables bites hardest. If the legacy records preserved the actual test values rather than the ranges they confer, the new system holds numbers it cannot reason about. Converting actuals to ranges is a code exercise that has to be done deliberately, documented as an interpretation, and reviewed — not something an import script should attempt on its own.

Film, digital radiography and the weld map join

Radiographic records are the largest volume of legacy data in most shops and the hardest to make useful. Film lives in envelopes indexed by job number. A job number may cover four hundred welds. The location of each shot is marked on a shooting sketch that exists as a marked-up print, sometimes scanned, sometimes not. Retention obligations run for years and are often extended by contract well beyond the shop's own QC manual requirement.

Migrating this is not primarily a scanning problem. Scanning is straightforward. The problem is the join: connecting an image to a specific weld on a specific component, which requires a stable weld identifier that the legacy system probably did not have, or had in three successive incompatible schemes as the numbering convention changed over the years. Without that join, a digitised archive is a searchable pile of images indexed by job, which is roughly what the envelopes already were.

The pragmatic approach is stratified rather than uniform. Establish the weld ID scheme and the map join for work that is still live, still under warranty, or belongs to customers who audit. Bulk-digitise the remainder with job-level indexing and accept it as an archive rather than a dataset. Trying to retrofit weld-level identity across twenty years of film is a project that consumes the migration budget and delivers its value to records nobody will ever query. Deciding this explicitly, early, and writing down where the line falls is worth more than the extra completeness would have been.

How to run the migration and how to judge it

Run the legacy system in parallel for one full cycle of the longest routine interval in scope — for most shops, twelve months. The purpose is not general caution. It is that a migration is only proven when the new system has independently derived a date, that date has come due, the work has been performed and the record has closed out. Annual obligations occur once. A three-month parallel run tests the import; it does not test the engine, and the difference matters because the engine is the part you are buying.

During evaluation, hand the vendor a genuinely dirty extract rather than a clean sample: mixed remaining-and-loss thickness conventions, heat numbers in four formats, a plate replacement mid-series, several assets with a single reading, and welder records holding actuals rather than ranges. Watch what the import does. Software that accepts all of it without complaint is the problem, not the solution. What you want to see is an exceptions queue, a refusal to guess, and a reconciliation report you can hand to a customer's quality representative.

Then ask the two questions that separate real products from demonstrations. Show me a date and tell me every input that produced it, including which rule and which rate provenance. And show me the same asset's date as it stood before the last reading arrived, with the reason it changed. A system that can answer both has kept its evidence. A system that can only show you the current date has thrown away the reason you would ever trust it. If you want to test this against a sample of your own legacy records rather than a demonstration dataset, contact info@atlantisndt.com; consultation and quotes are on request.

Request a consultation