Migrating an IDMS: registers, CMLs, and history intact

An inspection data management system holds two kinds of things. The first is the register: every vessel, line, tank and exchanger, with its design data and its inspection plan. The second is the history: every thickness reading at every condition monitoring location, going back as far as the plant has been measuring. The register is what people think they are migrating. The history is what they are actually migrating, because the corrosion rates, remaining lives and inspection intervals that justify the plan are all derived from it. An IDMS migration that moves the register perfectly and the history loosely produces a system that looks complete and computes wrong. This paper is about doing the second part properly.

What makes an IDMS migration different from a normal data migration?

Most business system migrations move records that are complete in themselves. An invoice is an invoice; moved intact, it is correct. Inspection data is different in three ways.

The valuable numbers are derived. A corrosion rate is not stored data; it is computed from two readings and the time between them. A remaining life is computed from the current thickness, the minimum thickness and the rate. The next inspection date is computed from the remaining life and a code rule. Move the readings imperfectly and every derived number changes, often without anyone noticing, because the target system happily computes a rate from whatever it was given.

Identity is layered. A reading belongs to a CML, which belongs to a component, which belongs to an equipment item, which belongs to a unit. A migration must preserve all four links. A reading attached to the wrong CML is worse than a missing reading, because it corrupts the rate at two locations.

The history is the evidence. An owner-user's inspection interval is defensible because the record shows the readings that support it. If the migration loses the 2009 baseline reading, the long-term rate on that CML is now computed from a shorter window and the interval that depended on it has lost its basis. A regulator or an auditor will ask for that basis.

The consequence is that an IDMS migration cannot be signed off on row counts. It has to be signed off on recomputation: the target must produce the same engineering answers as the source, or the differences must be understood and accepted by an engineer.

What has to survive: registers, CMLs, and history

It helps to name the layers explicitly and decide the acceptance test for each before any mapping begins.

• Equipment register. Tag, description, type, service, design code, design pressure and temperature, material, and the hierarchy position (site, unit, system). Acceptance: every tag in the source exists in the target at the correct hierarchy position, and no target tag lacks a source.
• Component and CML definitions. For each CML: identity, location description, component, nominal thickness, minimum thickness and the method that produced it, design pressure, material, outside diameter and schedule for piping, allowable stress, joint efficiency, corrosion allowance and grid geometry where it applies. Acceptance: every CML maps to exactly one target CML with all governing inputs populated.
• Reading history. Every thickness reading with its date, value, technician, instrument and any qualifier (estimated, obstructed, retaken). Acceptance: reading counts per CML match, and the earliest and latest dates match.
• Derived values. Short-term rate, long-term rate, remaining life, next inspection date, and any RBI risk rank. Acceptance: the target recomputes them and they match the source within a stated tolerance, or a documented reason exists.
• Findings and damage mechanisms. Recorded thinning, cracking, CUI and other mechanisms, with their status. Acceptance: mechanism records exist on the right components with their history.
• Attachments and reports. Signed inspection reports, drawings, photographs. Acceptance: every source attachment is reachable from the equivalent target record.
• Inspection plans and intervals. The current plan, its basis, and any deferrals with their approvals. Acceptance: the target shows the same due dates and the same basis.

Writing these down forces a conversation about what the source actually contains. It is common to discover at this stage that tMin exists in the source without any record of how it was derived, or that the "nominal" column has been overwritten with the latest reading on half the CMLs. Better to find that now.

How do you map CML data when the schemas differ?

No two IDMS schemas agree on what a CML is. Some treat it as a point with a single thickness history. Some treat it as a grid. Some store the design inputs on the CML and some inherit them from the component. The mapping exercise has to resolve these differences field by field.

A workable method:

1. Inventory every source field, with its type, unit, population rate and a sample of distinct values. Fields that are ninety percent empty deserve a question: were they never used, or used only at one site?
2. Classify each field as identity, design input, reading, derived value, or annotation. Derived values are not migrated as data; they are recomputed and compared.
3. Map each design input explicitly to the target field with the same engineering meaning. Nominal thickness maps to nominal thickness. A source field called "tmin" needs a decision: is it a code minimum, a corrosion allowance based minimum, or an engineer's retirement thickness? The target should carry the value and the method. A platform whose CML record includes tMin and its method as separate fields, as intelliSPEC's does across its 64 CML fields, makes this a mapping rather than a compromise.
4. Normalize units before load, and record the conversion. Mixed millimetres and inches inside one column are common in systems that have absorbed a previous migration.
5. Preserve source identifiers as a field on every target record. When a question arises in two years, the ability to say "this was CML 114-A in the old system" ends the argument.
6. Handle grids deliberately. If the source stored a grid as a single averaged reading, the target inherits that loss and should say so. If the source stored the grid, the target should have grid geometry to receive it.

Where the target supports workbook import with assisted column mapping, use the mapping suggestions as a draft, then review every governing field by hand. Assisted mapping is good at matching "Nominal Thk" to nominal thickness and bad at knowing which of three tmin columns is authoritative.

How do you validate that corrosion rates still compute the same?

Recomputation is the acceptance test, so set it up as a formal step rather than a spot check.

For every CML, after load, compute in the target:

• Short-term rate: (previous thickness minus current thickness) divided by the interval between those two readings.
• Long-term rate: (initial thickness minus current thickness) divided by the interval since the initial reading.
• Governing rate: the maximum of the two, unless the owner-user's procedure specifies otherwise.
• Remaining life: (current thickness minus tMin) divided by the governing rate.
• Next inspection interval: under API 510 and API 570, capped at half the remaining life and by the code's maximum interval for the equipment class.

Compare each against the source system's stored values and classify every difference.

• Rounding and precision differences are expected and should be within a tolerance the integrity engineer sets in advance.
• Definitional differences arise when the source used a different initial reading (for example, the first reading after a repair rather than the original baseline). These need a decision, recorded once and applied consistently.
• Data differences mean a reading is missing, duplicated or misattributed. These are defects in the migration and are fixed at the source of the load, not patched in the target.
• Method differences on tMin change the remaining life without changing the rate. Carry both values and let an engineer decide which governs.

The output of this step is a reconciliation report per CML that an engineer signs. It is also the single most useful document to keep, because in a future audit it demonstrates that the interval basis survived the migration.

If the new system gives a different next inspection date than the old one and nobody can say why, the migration is not finished.

What about attachments, reports, and the audit trail?

Three categories of history do not fit a field mapping and are often left to the end.

Attachments (signed reports, radiographs, photographs, drawings) must remain reachable from the record they support. The practical approach is to migrate them as files with a manifest that links each to its target equipment, component or CML, then verify the manifest by sampling. Files that cannot be linked to a record should be loaded against the equipment item with a note, never discarded. A drawing that is loaded and annotated in the target, with CML points detected on it, becomes more useful than it was in the source.

Legacy reports that exist only as PDFs are evidence, not data. Their readings should already be in the history; if they are not, the readings are transcribed as data with the PDF attached as source. See the separate paper on legacy report archives for the extraction method.

The source audit trail cannot be replayed into a new system as if the events happened there. Export it in full, store it with the migration evidence, and let the target's audit trail start with the import itself. In intelliSPEC, data import is an audited event that carries the actor, tenant, request identifier and device details into a hash-chained log that is never auto-deleted, so the moment of migration is itself part of the permanent record. An auditor can see who loaded what and when, and the source log covers everything before.

How should the cutover be sequenced?

A sequence that has held up across programs of different sizes:

1. Pilot unit first. Choose one unit with a full range of equipment types and a complete history. Migrate it, reconcile it, and run both systems in parallel through at least one inspection cycle. Discrepancies found here are cheap.
2. Freeze and extract. For each subsequent wave, freeze source edits for the wave's equipment, extract, load, reconcile. A moving source cannot be reconciled.
3. Reconcile and sign. No wave is complete until the recomputation report is signed by the responsible engineer.
4. Parallel run with a defined end. Field capture moves to the target on a stated date. The source becomes read-only and stays available for the duration of the next inspection cycle.
5. Retire the source deliberately. Take a final export, store it with the audit log and the reconciliation reports, and switch it off. A source that is never switched off becomes a shadow system.

Two habits make the difference. Keep the source identifiers on every target record, and keep the reconciliation reports. Together they answer every question anyone will ask about the migration for the next decade.

How intelliSPEC handles it

intelliSPEC's data model was designed to receive migrated history without flattening it. A CML record carries 64 fields, including nominal thickness, tMin and the method that produced it, design pressure, material, outside diameter and schedule, allowable stress, joint efficiency, corrosion allowance, grid geometry, the latest thickness and three corrosion rates, so a source system's governing inputs map to fields with the same engineering meaning rather than to a comments box. Damage mechanisms are first-class records, and the asset hierarchy is a graph of nodes with roles from company down to component and weld, so an equipment item can be placed correctly even when the source hierarchy was a fixed tree.

Loading uses workbook import with assisted column mapping, CSV, and an open API with 514 documented endpoints, and every import is written to the hash-chained audit trail. Once loaded, intelliINTEGRITY recomputes the derived values the reconciliation depends on: minimum thickness routed by equipment type to ASME B31.3, ASME VIII Division 1 or API 653 with the design code and formula returned alongside the number; short-term, long-term and maximum corrosion rates with the maximum governing; remaining life as (t minus tmin) divided by rate; and API 510 and API 570 intervals capped at half the remaining life. Fitness-for-service screening results are provisional until an engineer verifies them, and nothing is auto-derated, which is the behaviour a reconciliation needs. Field capture through intelliINSPECT then continues the history on the same records, offline if necessary, with source identifiers preserved. Definitions for the terms above are in the glossary.