Migrating Integrity Data Without Carrying the Old Errors Forward

The most useful rule in a migration is also the simplest: move the things that were observed, and let the new system calculate everything that follows from them.

A corrosion rate sitting in a spreadsheet cell is not a measurement. It is the output of a calculation whose inputs are a series of thickness readings, the dates those readings were taken, the location they were taken at, and a set of rules about which readings to use. API 510 and API 570 both distinguish between a short term rate calculated from the two most recent readings and a long term rate calculated from the original or earliest reliable reading, and they expect the more conservative of the two to govern unless there is a documented reason to do otherwise. None of that reasoning survives inside a single cell.

If the migration moves the rate rather than the readings behind it, three things become impossible. The rate cannot be recalculated when the next inspection happens. It cannot be re baselined after a repair or a replacement resets the measurement history. And it cannot be defended to an auditor who asks which readings produced it.

The same logic applies further down the chain. Remaining life follows from the current measured thickness, the required thickness, and the governing corrosion rate. The next inspection date follows from remaining life and the interval rules in the relevant code. Risk ranking follows from consequence and likelihood inputs that are themselves derived. Each of these is a calculated result, and each should be regenerated inside the new system rather than copied into it.

What must move, then, is the layer underneath all of that:

• Thickness and other condition readings, each with its date, its measurement location, the instrument or method used, and the person or contractor who took it.
• The physical definition of the monitoring locations themselves, including their position on the component and the reason they were placed there.
• Design and material data, which the next section deals with separately.
• Inspection reports, findings, repair records, and any written engineering judgment attached to them.
• The history of decisions that changed something, such as an interval extension, a rate override, or a decision to retire a monitoring location.

That last item is the one most often left behind, and it is the most expensive to lose. When someone extended an interval in 2019 on the basis of a corrosion study, the study is the record that matters. The extended date is only its consequence

Ask an integrity engineer where the nominal thickness of a particular vessel course is recorded and, in a legacy estate, the honest answer is often that it appears in four places. It is on the manufacturer’s data report in a filing cabinet, in the thickness monitoring spreadsheet, in a fitness for service calculation done three years ago, and in the maintenance system’s equipment record. In many plants at least one of those four disagrees with the others, and no one can say which is right without going back to the original document.

This is the condition that a migration either fixes or permanently freezes. The design and material data set, meaning materials of construction, design and required thickness, design pressure and temperature, maximum allowable working pressure, joint efficiency, corrosion allowance, applicable design code and year, and the associated manufacturer’s records, should be established once, verified against source documents, and then read by every calculation that needs it rather than re entered alongside each one.

There is a strong regulatory argument for treating this as the first task rather than a later cleanup. Under the OSHA process safety management standard, the employer is required to compile written process safety information on the equipment in the process, and that information explicitly includes materials of construction, design codes and standards employed, and relief system design. The standard further requires the employer to document that the equipment complies with recognized and generally accepted good engineering practice, and, for existing equipment built to codes no longer in use, to determine and document that the equipment is designed, maintained, inspected, tested and operating in a safe manner.

In other words, the data set that a modern integrity platform needs before it can calculate anything is very close to the data set the plant is already obliged to hold and keep current. A migration is the cheapest opportunity most organizations will ever get to close the gaps in it, because the work is already funded and someone is already opening every folder.

Two practical points follow. First, the verification should be against the original records, meaning the manufacturer’s data report, the nameplate, the as built drawing, or the repair documentation, and not against whichever spreadsheet appears most authoritative. Second, the exercise will find gaps. Vessels with no retrievable data report, piping circuits whose specification was never recorded, equipment whose design code predates the current edition by several revisions. These are findings, not obstacles. They existed before the migration started, and writing them down is a better outcome than continuing not to know.

In AsInt Edge this layer is a dedicated application, the Asset Centric Workbench, which holds the asset register together with the design and material data attached to each item. The other applications on the platform, thickness monitoring, inspection, fitness for service and risk based inspection among them, read from it rather than keeping a copy of their own. During a migration the practical consequence is that the design data is loaded and verified once, at the beginning, and everything added afterwards inherits it. When a manufacturer’s data report finally turns up in a cabinet six months later and a required thickness has to be corrected, the correction is made in one place and reaches every calculation that used the old value.

Very few of these projects are a clean replacement, and the ones that try to be are the ones that stall. Most plants already run SAP, Maximo, or an equivalent for their maintenance work, and that system will not be going anywhere. The integrity platform has to sit next to it.

The disruption in these projects almost never comes from the technical connection between the two systems. It comes from an unresolved disagreement about who owns which piece of information. Both systems can hold an equipment tag. Both can hold a description, a location, and a status. If that overlap is not settled before the first record moves, the two systems drift apart within months and the engineers quietly go back to keeping a spreadsheet as a reconciliation between them, which is the situation the project was meant to end.

The boundary that works in practice runs along the line between work and condition. The maintenance system remains the record for the equipment master, functional locations, notifications, work orders, and the cost and scheduling that attach to them. The integrity platform becomes the record for measured condition, damage mechanisms, inspection strategy, and the engineering assessments that set intervals. Where the two must agree, such as the equipment tag itself, one side is named as the origin and the other receives updates from it, field by field and with the direction of flow written down.

Getting this stated on paper, ideally as a table that lists each shared field, its owning system, and its update direction, does more to protect the schedule than any amount of technical preparation. It is also the artifact that lets a plant run more than one maintenance system, which is common after an acquisition, without the integrity program having to pick a favorite.

Connectivity matters more here than it first appears. AsInt Edge connects to more than one maintenance system rather than assuming a single one, so the boundary can be drawn where the plant needs it instead of where the software forces it. An operator running SAP at some sites and something else at others, which is the normal state a few years after an acquisition, can keep one integrity program across all of them while each site keeps the maintenance system it already has. The equipment tag still originates on the maintenance side in every case. Only the connector changes.

Once the data hierarchy and the ownership boundary are settled, the difficult work begins, which is deciding what to do with records that are neither clearly good nor clearly wrong.

A workable approach sorts every record into one of four dispositions:

1. Move as it stands. The record is complete, internally consistent, and traceable to a source. Most recent inspection data falls here.
2. Move with a flag. The record is usable but unverified, typically because its source document could not be located or because a value looks plausible without being confirmable. It goes into the new system, it is available for calculation, and it carries a marker that tells the next engineer to treat the result with care and resolve the flag at the next opportunity.
3. Archive without calculating. The record is worth keeping for history but should not feed any live result. Readings from a monitoring location that no longer exists, measurements taken with a method that was later found unreliable, or data from equipment that has since been replaced belong here. It stays searchable and retrievable, which matters for the record retention requirements in the inspection codes, but it does not influence a corrosion rate.
4. Rebuild from source. The record is wrong or unusable and the correct value can be recovered from an original document or a new measurement. Design data usually dominates this category.

The criteria for sorting need to be written down before anyone starts, and they should be specific enough that two engineers working separately would classify the same record the same way. Useful tests include whether a physically impossible value is present, such as a thickness that increased between inspections without a repair; whether a reading can be tied to a named location and a real date; whether design data can be matched to a source document; and whether an override or manual adjustment has any recorded justification.

One point about the second disposition is worth stating plainly, because it is where the sorting usually breaks down in practice. A flag has to be an attribute of the record that the software carries, displays next to the calculated result, and can report on. A note typed into a comment field is not a flag. If the platform cannot list every flagged record on demand, the flags will not be resolved, and the migration will have created a second category of quietly unreliable data to sit alongside the first.

Expect the volume to be uncomfortable. On a first pass through a mature spreadsheet estate it is common for a meaningful share of monitoring locations to fail at least one of these tests. That number is not a reflection on the people who kept the spreadsheets. It is the accumulated result of staff turnover, contractor changes, file copying, and twenty years of small decisions made without a place to record them.

A migration that claims nothing was lost has to demonstrate it, and a record count does not demonstrate it.

The check that works is a parallel run on a limited scope. Pick one unit or one equipment group with a good mix of damage mechanisms and a reasonable inspection history. Migrate it fully. Then, for one complete inspection cycle, keep the legacy process alive alongside the new system and compare what each produce. The comparison should cover the calculated corrosion rates, the remaining life figures, the resulting inspection due dates, and the risk ranking if a risk-based inspection program is in place.

The important rule is that every difference must be explainable. Not acceptable, not within tolerance, but explainable, with a named cause. A difference because the new system applied the governing rate rule consistently where the spreadsheet had used a single long-term rate throughout is explainable. A difference because the new system excluded a reading that the spreadsheet had included is explainable, once someone identifies which reading and why. A difference nobody can account for means the migration rules are wrong somewhere and the remaining scope should not proceed until it is found.

The result that surprises project sponsors, and the one worth preparing them for, is that most unexplained differences turn out to be errors in the legacy data rather than faults in the new system. This is a good outcome but it does not feel like one in the moment, because it arrives as a list of things the program has been getting wrong. It is worth agreeing in advance how those findings will be handled, particularly where a corrected corrosion rate shortens an interval on equipment that is already close to due.

There is a cost to this approach that should be stated plainly. A parallel run consumes engineering time on the pilot scope twice over, and it extends the schedule by whatever a full inspection cycle takes on that equipment. Some organizations compress it by running the comparison against historical data rather than waiting for live inspections, which is faster and catches most calculation differences, though it cannot test the field workflow. Either version is better than skipping the check.

The instinct is to migrate one unit at a time, or one data type at a time, because both are easy to plan. A better order is by risk and by proximity of the next inspection.

Equipment carrying high consequence damage mechanisms, and equipment with an inspection falling due in the next twelve months, should move first. The reason is verification speed. Data that gets inspected soon gets checked against reality soon, which means errors surface while the migration team is still assembled and can correct both the record and the rule that produced it. Equipment that is not due for six years yields no feedback for six years.

This ordering also protects the program if the project loses momentum, which happens more often than anyone plans for. If a migration stalls halfway, a program that sequenced by risk has its critical equipment in the new system and its low consequence equipment still in spreadsheets, which is manageable. A program that sequenced alphabetically by unit has an arbitrary half of its risk in each place, which is not.

The shape of the platform can support this sequencing or fight it. AsInt Edge is organized as a set of applications added to a workspace as they are needed rather than switched on together, and workspaces can be scoped to a project or a site. A program can begin with the asset register and thickness monitoring, prove the reconciliation on one unit, and bring in inspection, fitness for service and risk based inspection afterwards, each one landing on design and material data that has already been verified. Turning everything on at once and populating it in parallel is what makes these projects feel disruptive, and it is rarely necessary.

The habit worth breaking is treating a migration as a transfer problem measured by completeness. Judged that way, the most successful migration is the one that changes nothing, and a program that has been quietly running on bad data ends up with the same bad data in a system that makes it harder to challenge.

The alternative is to treat the migration as the one moment when every record gets looked at by someone. Move the observations and rebuild the calculations from them. Establish design and material data once, verified against original documents, and let every application read it from there. Settle the ownership boundary with the maintenance system on paper before any data moves. Sort the doubtful records deliberately, with written criteria, and be willing to archive or rebuild rather than carry something forward for the sake of a record count. Prove the outcome with a parallel run in which every difference has a name. Sequence the work so the highest risk equipment is verified first.

Done this way, the migration produces something more valuable than a populated database. It produces a defensible account of what the organization knows about its equipment, what it does not know, and which of the two applies to any particular number.