Migrating chemical plant inspection history without losing the math

Remaining life is derived, so migrate the inputs

The instinct on a migration project is to map columns. The legacy system has a next inspection date, the new system has a next inspection date, so the mapping is obvious and the project plan says three weeks. What that mapping actually does is freeze twenty years of undocumented judgement into a system that was bought specifically to remove undocumented judgement.

A due date is the last term in a chain: dated readings produce a corrosion rate, the rate and the required thickness produce a remaining life, the remaining life and a code ceiling produce an interval, and the interval and the last inspection date produce the date. Migrating the last term and none of the others means the new engine can display a date it cannot explain, cannot recompute when a reading arrives, and cannot defend when an auditor asks how it was derived.

So the migration scope is set by the calculation, not by the screens. Every input the engine needs must come across with enough fidelity to reproduce a number: the location register with verified physical positions, every dated reading with its measurement method and instrument, nominal and required thickness with the basis of the required value, design code and design conditions, material of construction, service and campaign history, and the dated events that changed any of those. Anything that is derived - rate, remaining life, interval, due date - should be recomputed on arrival and reconciled against the legacy value, never imported as fact.

CML identity is the whole migration

Thickness readings are meaningless without a stable answer to the question of where they were taken. In a legacy database that answer often lives in a technician's memory, a hand-marked isometric, or a numbering scheme that was renumbered when a contractor changed in 2014. The migration is where that ambiguity becomes permanent.

The failure is quiet and specific. If historical readings from one physical point are loaded against a different point, the series contains a step - a jump of forty or eighty thousandths in a single interval. Software that trusts its inputs will read that step as either a dramatic corrosion event, generating a remaining life of two years and a panic, or as negative corrosion, generating an infinite life and a silent disappearance from the schedule. The first gets investigated. The second does not.

The mitigation is unglamorous: verify location identity before loading readings, using isometrics, grid drawings, photographs and, where the record is genuinely unrecoverable, a fresh baseline scan. A location whose identity cannot be established should be loaded as a new location with a new baseline rather than inheriting a history that may belong somewhere else. Losing ten years of history at a handful of points is a far smaller loss than propagating a rate that is fabricated.

The replacement event that produces infinite life

Chemical plants replace components constantly. A corroded spool in a wet acid line is cut out and replaced during a short shutdown, the work order closes, and in many legacy systems nothing about the thickness history changes. The readings before and after the replacement sit in the same series.

The arithmetic then does something dangerous. Suppose the location read 0.290 inch in 2007, thinned to 0.210 by 2012, was replaced with a nominal 0.375 wall in 2013, and read 0.360 in 2019. A long-term rate computed from 2007 to 2019 is negative. Clamped to zero, it produces an infinite remaining life. The interval defaults to the code ceiling, the asset stops appearing in any due-soon report, and the only thing that will bring it back is an incident or a lucky audit. On the same data, the correct calculation uses only the post-2013 readings and returns a rate of roughly 2.5 mpy.

This is why replacement, repair and re-rate events are first-class migration objects rather than metadata. They tell the engine where a series legitimately restarts. A migration that carries readings but not events will look complete, load cleanly, validate against record counts, and still be wrong on every component that has ever been repaired - which in a chemical plant is most of the corrosive service.

Campaign operation, and the rate that legacy systems smeared

Refineries run continuously in one service for years. Chemical manufacturing frequently does not. A multi-purpose reactor train may run an esterification campaign, be washed, run a chlorination campaign, be neutralised, and sit idle for two months, all within a single year. Each of those states has its own corrosion behaviour, and the aggressive one may occupy fifteen percent of the calendar and cause ninety percent of the metal loss.

A legacy system that stores only readings and dates fits a straight line through that pattern and calls the slope a corrosion rate. The number is arithmetically valid and physically meaningless. It will under-predict life if next year's plan is light on the aggressive campaign and over-predict it badly if the plan doubles that campaign - and the plan is a commercial decision made after the inspection interval was set.

Migration is the one opportunity to segment that history properly. If production records can supply dated campaign periods, readings can be attributed to operating periods and rates computed per service. The projected life then becomes a function of the production plan, which is exactly the conversation an integrity engineer wants to be having with a plant manager who has just won a new contract for the aggressive product.

Lined, clad and non-metallic equipment that thickness math does not describe

A large share of chemical plant equipment is not a bare steel wall. Glass-lined reactors, rubber-lined tanks, PTFE-lined piping, clad and weld-overlaid vessels, and fibre-reinforced plastic equipment built to ASME RTP-1 or ASME Section X all fail by mechanisms that ultrasonic wall thickness on the substrate will not detect. A glass-lined reactor with a pinhole in the lining has full wall thickness and a live corrosion problem behind the glass.

For these assets the interval is condition-based rather than rate-based: spark testing and holiday testing on linings at a frequency driven by service and lining age, visual and acoustic emission approaches on FRP, and thickness measurement on the substrate treated as a confirmatory rather than a primary measurement. Clad equipment needs the clad layer and the base metal tracked separately, because the moment the cladding is breached the corrosion rate that applies is the base metal's, not the historical trend.

Legacy systems commonly forced these assets into the same thickness schema as carbon steel piping, producing a register full of nominally healthy equipment with meaningless remaining lives. Migration should reclassify them onto a condition-based regime rather than reproducing the fiction, and the engine has to be able to hold both regimes in one schedule so nothing drops out of the due-work list.

Equipment outside API 510, and how the interval is defended

Chemical plants carry a long tail of equipment that no construction or inspection code cleanly governs: atmospheric mix tanks, day tanks below the pressure threshold, filter housings, dryers, non-jurisdictional vessels built to a fabricator standard, and equipment inherited from an acquisition with no design file at all. Much of it holds a highly hazardous chemical and is therefore squarely inside the process safety management standard.

Under 29 CFR 1910.119(j)(4), inspection and testing must follow recognised and generally accepted good engineering practice, and where no code applies the owner-user has to establish that practice in writing. That written basis is the interval's defence, and it needs to cite something real: service severity, consequence of loss of containment, condition observed at previous inspections, manufacturer guidance, or an internal engineering standard.

The system implication is that the engine cannot only understand API-coded assets. It needs a policy-driven regime that produces intervals for non-coded equipment from the same asset register, using the same event model and the same override mechanism, so those items appear in the same schedule and the same overdue count as the pressure vessels. Equipment that lives outside the system lives outside the programme in practice, whatever the written procedure says, and an auditor who finds the side spreadsheet has already found the finding. Migration is the natural moment to pull that tail in, because the tail is usually exactly the equipment the legacy system could not represent.

Validation rules that must fire during the load

A migration that checks only record counts will load nonsense cleanly and report success. The rules worth enforcing at the point of load are the ones that catch physically impossible data: a reading greater than nominal thickness plus mill tolerance, a reading already below the recorded minimum required thickness with no fitness-for-service assessment attached, a negative computed corrosion rate, two readings at one location on the same date with different values, a reading dated before the equipment was commissioned, a location with readings but no parent component, and a rate that implies the wall was thicker than the material was ever supplied.

Each of those has a distinct and diagnosable cause. Readings above nominal usually mean a mis-mapped location or a coating measured along with the wall. Readings below minimum with no assessment attached mean either a transcription error or a real, unaddressed finding the legacy system was carrying quietly - and the second is something you want to discover on day one of the project rather than in year two of the new system. Negative rates almost always mean a missing replacement event or a renumbered condition monitoring location. Same-date duplicates mean two contractors surveyed the same line and neither knew.

The rules should quarantine rather than reject. A record that fails validation has to be visible, assigned to someone and resolvable, never silently dropped, because a migration that discards its problem records produces a clean-looking register with holes in exactly the places where the previous programme was weakest. Count the quarantine, work it down unit by unit, and make its remaining size an explicit gate on cutover rather than a footnote in a status report.

Reconciliation, not conversion: how to prove the migration

Migration success is not a load report. It is a reconciliation. Recompute every asset in the new engine from migrated inputs, place the derived date next to the date the legacy system was working to, and sort by the size of the difference. That list is the deliverable, and the project is finished when every material difference has an explanation, not when the difference count reaches zero.

Expect three categories. The legacy value was wrong - a typed date, a stale rate, an interval never recomputed after a re-rate. The migration was wrong - a mis-mapped location, a missing replacement event, a unit conversion. Or both are right and the rule differs, which is where you discover the undocumented convention your corrosion engineer has carried in their head for fifteen years. Each category has a different owner and a different fix, and the third is usually the most valuable output of the whole project.

Run the legacy system as authoritative until reconciliation is signed off, unit by unit rather than plant-wide, and cut over per unit. Keep the legacy extract archived unchanged as the evidentiary record of what the previous programme said, because an auditor may ask about a date that was current three years ago. Atlantis inspection management software is configured against your existing codes, written programme and legacy extract, with the reconciliation built as part of implementation rather than left to the customer. A scoping consultation with an ASNT Level III is available on request through info@atlantisndt.com.

Request a consultation