Switching NDT Reporting Software: A Migration Checklist for Inspection Companies

Most companies put off switching until the old system is actively hurting them

Inspection companies rarely switch reporting software proactively. It usually happens reactively — a legacy platform the company outgrew years ago finally has a data loss scare, a client's audit turns up formatting inconsistencies traced back to broken templates, or a founder who built the original Word-template-and-shared-drive workflow finally admits it can't scale past the current headcount. By the time the decision gets made, there's real urgency, and urgency is exactly the condition under which migrations go wrong — corners get cut on data validation, staff get minimal training before go-live, and nobody schedules the cutover around the company's actual workload calendar.

A migration done carelessly doesn't just risk a rocky first month on the new platform. It risks losing or corrupting historical inspection records that carry real retention obligations — API 510 and API 653 both drive multi-year retention expectations for pressure vessel and tank records, and many client contracts specify retention tied to equipment design life, not a fixed short window. Getting the migration right matters as much as picking the right platform to migrate to.

What "clean data export" actually requires from the old system

The first checklist item isn't about the new system at all — it's making sure everything of value comes out of the old one intact. This is harder than it sounds when the legacy system is a mix of a database-backed tool and years of accumulated Word documents and PDFs on a shared drive, because "export" means different things for structured data versus static files.

• Structured report data — readings, CML values, indication logs — needs to export in a format that preserves the relationship between data points, not just as a flattened PDF that turns structured numbers back into unstructured text someone has to re-extract manually.
• Static historical reports (PDFs, scanned documents from before digital reporting) need a clear indexing scheme so they remain findable by asset, client, and date after migration, even if they're not converted into the new system's structured format.
• Calibration and equipment records tied to historical reports need to migrate with the reports they support — a historical report without its calibration context loses a meaningful part of its defensibility.
• Personnel certification records current as of each historical report's date need to be preserved, even for staff who've since left the company, since audits can reach back into records generated by former employees.

Mapping fields: nothing transfers one-to-one

Every reporting system structures its data slightly differently, and assuming a clean field-to-field mapping between old and new systems is one of the most common sources of migration errors. A field the old system called "Client Ref" might map conceptually to "Purchase Order Number" in the new system, but if a data migration script maps it blindly without someone reviewing a sample of actual records, subtle mismatches creep in — dates in different formats, technician names recorded inconsistently (initials in one system, full names in another) that fail to match against a certification database during import, or units of measurement that need explicit conversion rather than a direct copy.

The practical approach is to migrate a representative sample first — a few dozen reports spanning different clients, methods, and date ranges — and have someone who actually understands the technical content review the migrated output against the originals before running the full historical migration. Catching a systematic mapping error in a fifty-record sample is a minor fix. Catching it after migrating five years of records is a much bigger cleanup.

Migrating the procedure and template library, not just report history

It's easy to focus a migration entirely on historical report data and treat the procedure library, acceptance criteria tables, and client-specific templates as something to rebuild from scratch in the new system. That's a mistake for two reasons: it's a large amount of avoidable rework, and rebuilding from memory risks silently changing acceptance criteria or procedure references in ways nobody intended, introducing errors that only surface months later when a report doesn't match what a client expects based on prior history. Wherever possible, migrate the procedure library and template structure directly, with a technical reviewer — ideally a Level III — signing off that the migrated criteria match the original exactly before the new templates go live.

Calibration and personnel records: the two things that can't have gaps

Of everything being migrated, calibration history and personnel certification records deserve the most conservative handling, because gaps in either one create compliance exposure that's disproportionate to how small a data-entry mistake might seem. A calibration record that fails to migrate cleanly can make it look, on paper, like an instrument had a gap in its calibration currency that never actually existed — or worse, can hide a real gap that did exist. Both outcomes are bad, for different reasons. The safest approach is validating calibration and personnel data migration item-by-item against the source system before decommissioning it, rather than spot-checking a sample the way is reasonable for less compliance-sensitive data.

Timing the cutover around your workload, not the vendor's calendar

A software vendor's implementation timeline is built around their delivery capacity, not around when an inspection company can actually absorb the disruption of a system change. Going live on a new reporting platform in the middle of a major client's turnaround, when every crew is at maximum load and there's zero slack for staff to be relearning how to generate a report, is close to the worst possible timing — even if the vendor's project plan says the implementation is "ready." The better approach is identifying the company's actual slow season or a gap between major jobs and insisting the cutover happen there, even if that means the migration project runs longer in calendar time than the vendor originally proposed.

Running parallel before trusting the switch

For at least a handful of jobs, running the old and new systems in parallel — generating the same report both ways and comparing output — catches problems no amount of upfront testing surfaces, because real field conditions (an unusual asset configuration, a technician entering data slightly differently than the test cases anticipated) expose edge cases that clean test data doesn't. This adds short-term overhead but is far cheaper than discovering a systemic issue after the old system has already been decommissioned and there's no fallback.

Telling clients before they notice on their own

Clients who've gotten used to a particular report format, a particular portal login, or a particular way of receiving data notice when something changes — and finding out about a software migration because a report suddenly looks different, with no advance notice, reads as a lack of control on the inspection company's part, however smooth the actual migration was internally. A short, proactive notice to active clients ahead of the cutover — what's changing, what stays the same (their format requirements, their acceptance criteria, their access to historical data), and who to contact if something looks wrong — costs very little and prevents a confused phone call from turning into a confidence problem.

A realistic migration checklist

• Export and validate all structured historical report data, with a sampled field-mapping review before full migration.
• Index and preserve static historical documents that won't convert into structured format.
• Migrate calibration and personnel certification records with item-by-item validation, not sampling.
• Migrate the procedure and acceptance criteria library with Level III sign-off on accuracy.
• Rebuild client-specific templates against the migrated core library, not from scratch.
• Schedule the cutover during a genuine workload lull, not the vendor's preferred timeline.
• Run a parallel period on live jobs before decommissioning the old system.
• Notify active clients ahead of the change, with a clear point of contact for issues.
• Keep the old system accessible in read-only form for a defined period after cutover, as a safety net.

None of this is complicated in isolation. What makes migrations fail is skipping steps under time pressure, because the old system's pain finally became urgent enough to force a decision. Treating the switch as a project with its own timeline — separate from whatever crisis prompted it — is what keeps historical records intact and clients confident through the transition.

Budgeting real time for the migration, not the vendor's estimate

Software vendors, understandably motivated to close the sale and get a new customer live, tend to quote migration timelines on the optimistic end — often based on a best-case data set that's already reasonably clean and well-organized. Most inspection companies' actual historical records don't look like that best case: years of inconsistent naming conventions, several different people's individual habits for organizing files, template variations that were never tracked, and gaps where records exist only as paper that was scanned inconsistently or not at all. The realistic move is doubling whatever timeline a vendor proposes for data migration specifically, and treating the vendor's estimate as the floor for a best-case scenario rather than the expected outcome — a posture that protects the company from the common experience of a migration that was "supposed to take three weeks" stretching into three months once the actual condition of the historical data becomes clear.

Assigning a single internal owner, not a committee

Migrations that get treated as a shared responsibility across several people tend to have gaps nobody notices until well after cutover, because everyone assumes someone else is checking a particular category of records. Naming one specific person — with the authority to pause the cutover if something doesn't check out — as the internal owner of the migration, accountable for the whole checklist rather than a piece of it, meaningfully improves the odds that a genuine problem gets caught before go-live rather than after.

What to do if the migration reveals gaps in historical records

It's worth preparing for an uncomfortable but common outcome: migrations frequently surface the fact that historical record-keeping in the old system had gaps nobody previously knew about — a stretch of reports from several years ago missing their associated calibration records, personnel certification history that wasn't retained past a certain point, or a client's reports that exist only as low-resolution scans with data that's difficult to verify. Discovering this during a migration is uncomfortable, but it's considerably better than discovering it during a client audit, because it happens on the company's own timeline rather than in front of an external reviewer. The right response is documenting exactly what's missing and why, rather than quietly working around the gap or, worse, backfilling records with reconstructed data presented as if it were original — a temptation worth naming directly, because it turns an honest historical gap into a much more serious integrity problem if it's ever discovered. A documented, acknowledged gap in old records is a manageable finding. A fabricated record covering for that gap is not.

Training staff on the new system before go-live, not during it

A well-executed data migration can still fail at adoption if staff are handed a new interface on their first day with the new system and expected to learn it live, on a real job, under real schedule pressure. The more reliable approach is running structured training sessions on the new platform using sample or migrated historical data before the cutover date — letting technicians and reviewers generate a few practice reports, make mistakes, and ask questions in a setting where nothing is actually being delivered to a client. Companies that skip this step in the interest of moving faster typically pay for it in the first two or three weeks after cutover, when report turnaround slows noticeably because every technician is simultaneously learning a new tool and trying to keep up with a normal workload — exactly the period when clients are watching most closely for signs the switch was a mistake.

Keeping a rollback option genuinely available, not just theoretical

However confident a company is in a new reporting platform, keeping the old system accessible in a read-only state for a defined period after cutover — sixty to ninety days is a reasonable window for most inspection companies — provides a genuine safety net if a serious problem surfaces that wasn't caught during parallel testing. This is different from keeping old data archived somewhere inaccessible; the old system needs to still be functionally usable, at least for lookup and export, in case a specific historical record needs to be pulled and something about the migration turns out to be wrong. Decommissioning the old system the day after cutover, before the new system has had time to prove itself across a real, varied workload, removes that safety net exactly when it might still be needed.

Atlantis NDT Products & Services

Atlantis NDT pairs field expertise with software: NDT inspection management software — Atlantis ERP, a digital twin platform for asset integrity, and NDT reporting software. Build your team with NDT training & certification (ASNT SNT-TC-1A) and ASNT certification pathways, or bring in ASNT Level III consulting. Affordable, accessible, fully customizable — book a free consultation.