Migrating Years of NDT Findings Into a New Aerospace Deficiency System

You are migrating evidence, not data

The framing that makes an aerospace migration go well is deciding, before the first extract, that the object being moved is evidence. A deficiency record in a repair station or a build shop exists to prove that a qualified person, using a qualified technique, applied a defined acceptance criterion to a specific serialised item and reached a recorded conclusion which a person with authority then dispositioned. Every field is load-bearing. Drop one and the record degrades from evidence to anecdote, silently, with no error message.

This is why generic migration advice misleads here. Commercial data migrations optimise for completeness and speed, and treat a lossy field as a cosmetic problem to fix later. In aerospace, a finding whose technique reference did not survive cannot be defended in a customer audit, and there is no later — the job closed, the people moved on, and the reconstruction cost is enormous. The right posture is that any record that cannot migrate with its chain intact goes into a marked quarantine set and is dealt with deliberately, not blended into the main population.

Set that rule at the start and it changes the plan. You will migrate fewer records in the first pass, you will know exactly which ones are compromised, and you will be able to answer the only question that matters in an audit six months after cutover: is this record complete, and if not, why not, and who decided that.

The asset is a serial number that moves

Most deficiency modules are built for fixed plant, where a finding belongs to a location — a vessel, a line, a circuit — and stays there. Aerospace inverts that. A high-pressure turbine blade set, a landing gear cylinder, an actuator or a rotating disk carries its own history across airframes and shops. The finding belongs to the serialised item; the engine position, the aircraft registration and the shop visit are contextual attributes at a point in time.

Legacy systems very often got this wrong, or got it half right. A common pattern is that the shop's work-order system was the system of record, so history is organised by visit rather than by part, and the only way to assemble a component's life is to search visits for its serial. That works while the data is in one system with one search. It stops working the moment you migrate, because the join was never a foreign key — it was a text field that people typed, sometimes with a dash, sometimes without, sometimes with the shop's own tag rather than the manufacturer's serial.

Plan for this explicitly. Extract every distinct value that appears in a serial field, normalise the obvious formatting variants, and then look hard at what remains. Expect to find shop-assigned tags reissued after overhaul, which is the dangerous case, because merging on serial alone will graft one part's history onto another. The safe rule is to merge only where serial and a plausible date range agree, and to quarantine the rest for human review.

NADCAP replays the job, so the chain must survive

AC7114 audits do not assess a policy document; they sample jobs and follow them end to end. For a penetrant inspection, that means the technique or process instruction, the qualified process parameters, the penetrant, emulsifier and developer batch numbers with their verification results, the system performance checks, the light and darkness readings, the operator's NAS 410 or EN 4179 level and current vision test, the acceptance criteria per ASTM E1417 or the customer specification, and the recorded indication and disposition. The equivalent chains exist for MT under ASTM E1444, and for UT, RT and ET under their slash sheets.

In a legacy system that chain was frequently distributed across four places: the finding in a database, the technique sheet in a document control system, the batch verification in a lab log, and the disposition on a paper MRB form in a filing cabinet. Nobody noticed, because everyone knew where to look. The migration removes the people who knew. If the new system holds the finding but not the pointers, the first audit after cutover becomes an exercise in showing that you used to be compliant.

The practical countermeasure is to test the chain before you commit to the migration design. Pick ten historical jobs at random from three different years and three different methods, and try to assemble the full package by hand out of the proposed target data model. Whatever you cannot assemble is a gap in the model, and it is far cheaper to find it now than to find it with an auditor at the table.

Disposition, MRB authority and the field the old system never had

AS9100D clause 8.7 requires nonconforming outputs to be identified, controlled and dispositioned by an authorised person, with the disposition and the authority recorded. In practice the dispositions are familiar — use as is, rework, repair, scrap, return to supplier — and the authority is where migrations quietly fail. A use-as-is on a design characteristic often requires design authority concurrence, which in an FAA context may involve a DER or an ODA unit, and in an OEM context a specific delegated approval from the prime.

Legacy systems frequently stored disposition as free text and kept the authority on a signed form outside the system. Migrated literally, you end up with thousands of records saying repair per SB with no indication of who had the authority to say so. That is not merely untidy — it is the difference between a controlled nonconformance and an undocumented one, and it is exactly what a customer audit of your escape and concession history looks for.

Handle it deliberately. Model disposition and approving authority as separate structured fields in the target, migrate the legacy text into a preserved original-value field so nothing is lost, and populate authority only where it can be resolved from a signed source. Where it cannot, mark the record as authority-not-migrated rather than blank. A blank looks like an oversight; an explicit marker documents a known, bounded limitation of the migration, which is a defensible position.

Film, DICONDE and the images that must move with the finding

Radiographic and increasingly digital image data is the part of the migration most likely to be deferred and most likely to matter. Film-era jobs point at envelope numbers in a physical vault; digital radiography produces DICONDE files under ASTM E2339 that were often written to a departmental server with a folder convention rather than into the inspection system. Ultrasonic instruments produce proprietary data files with their own viewers. Eddy current produces C-scan data that is meaningless without the setup.

The question to answer for each image class is not whether it can be copied but whether it can be rendered in five years by someone who was not there. A DICONDE file with its metadata intact is portable. A proprietary UT data file whose only viewer runs on an operating system you no longer deploy is not, and neither is a folder path on a server scheduled for decommissioning. Where portability is doubtful, generate a rendered, human-readable representation alongside the native file and attach both to the finding.

Sample the retrievability before cutover rather than assuming it. Take fifty findings that reference an image, spread across the full date range, and attempt actual retrieval. The failure rate in that sample is your real image migration risk, and it is almost always higher than anyone in the room expects, particularly for the oldest and the most recent records — the old because media has aged, the recent because the folder convention changed and nobody updated the pointer.

Reconciling the migration: the numbers that must match

Row counts are a comfort blanket. They match while the migration is wrong, because the common failures — status mis-mapping, date field confusion, merged serials — preserve row counts perfectly. Reconcile on derived figures instead, because those are what people will actually use the system to produce.

Three reconciliations catch most of it. First, produce the aged-open deficiency list in both systems as at the same cut date and compare item by item, not just in total; a discrepancy here means your status mapping is wrong. Second, reconcile counts by disposition category by year; a spike or a hole in one year usually means a legacy code that changed meaning at some point and was mapped with a single rule. Third, reconcile by NDT method and by inspector; a method that vanishes or an inspector whose entire history lands in one year points at a field that was reused for two purposes.

Do these on the full population, not a sample, and do them twice — once on a rehearsal migration and once on the production run. The rehearsal exists to find the mapping errors; the production run exists to prove the same rules produced the same result on the real data. Keep both reconciliation outputs as migration validation records, because they are the evidence that the migration itself was controlled, which is a question a thorough auditor will ask.

Dual running, cutover and the first ninety days

The temptation is a hard cutover on a weekend. The safer pattern in a repair station is a period of dual entry for new findings only, typically two to four weeks, with historical data already migrated and frozen. Dual entry is unpopular and it is worth it: it surfaces workflow mismatches, missing finding types and permission problems while the old system still works, and it gives you a live comparison set for reconciliation on records whose ground truth you know.

Freeze the historical population early and treat it as read-only from that moment. If the legacy system continues to accept edits to old findings after the extract, your reconciliation is chasing a moving target and you will never close it. Announce the freeze date, extract, reconcile, and handle any genuinely necessary post-freeze legacy edit as a documented exception applied to both systems.

Plan the first ninety days after cutover as part of the project rather than as business as usual. The specific things to watch: findings entered against the wrong serialised item because the search behaves differently, dispositions recorded without authority because the new required field is being bypassed with a placeholder, and a quiet drop in findings raised because technicians find the new capture flow slower in the cell. All three are recoverable in the first quarter and expensive after it.

How an aerospace buyer should evaluate this module

Run the evaluation on your own legacy extract, not on demonstration data. Give the vendor a redacted sample spanning your oldest and newest records, including the awkward cases — the quarantine candidates, the reused tags, the free-text dispositions — and ask them to load it and then produce a full audit package for three named jobs. What you learn from that exercise is worth more than any feature list, because it tests the target data model against the actual shape of your history.

Then test the things that make the system usable after migration. Can an inspector raise a finding against a serialised item from the shop floor with the technique sheet attached and the acceptance criterion selected rather than typed? Can a Level 3 see every open finding raised under a technique they own, which is the practical form of the responsibility NAS 410 assigns them? Can quality produce an aged-open list filtered by customer, by programme and by disposition without an export to a spreadsheet, because the moment the answer is a spreadsheet you have recreated the problem you left.

Atlantis builds inspection management and reporting software on Odoo, configured to serialised-item history, structured disposition and authority fields, and retrievable evidence chains rather than a fixed data model — affordable, accessible and fully customisable. Bring a legacy extract to a working session and we will map it against the target model before anyone commits to a migration plan. Contact info@atlantisndt.com to arrange one.

Request a consultation