NDT ERP Migration Guide: Moving Off Spreadsheets Without Losing Historical Data

Why NDT Companies Wait Too Long to Leave Spreadsheets

Almost every NDT company that has been operating for more than five years is running some part of its business on a spreadsheet, and there's a good reason it happened: spreadsheets are free, flexible, and nobody had to ask permission to build one. A scheduling tab turns into a certification tracker, which turns into a calibration due-date log, which turns into a jerry-rigged job costing sheet with macros only one person understands. The system works — until that person goes on vacation during a turnaround, or a client audit asks for a complete calibration traceability chain going back three years and the answer is scattered across fourteen versions of "Calibration Log FINAL v3 (2).xlsx" on three different laptops.

The trigger for migration is rarely "we want new software." It's usually a near-miss: a technician dispatched with an expired certification because the tracker wasn't updated, a client audit that took two weeks of manual reconciliation instead of two hours, or a growth spurt that outpaced what one overworked office manager can keep current by hand. By the time the decision gets made, the spreadsheets often hold years of calibration records, certification histories, and job data that the company legally and contractually needs to keep — which is exactly what makes migration feel risky. This guide walks through how to move that data into a proper NDT ERP system without losing the audit trail that took years to build.

Step One: Audit What You Actually Have

Inventory Every Source of Truth

Before touching a migration tool, list every spreadsheet, shared drive folder, and paper binder that currently holds operational data: technician certification records, equipment calibration logs, job history, client contact and contract terms, source inventory logs for radiography, and inventory of consumables. Most companies are surprised to find the "real" data is split across six files with three different formats for the same field — one calibration log uses MM/DD/YYYY, another uses DD-MMM-YY, and a third just has "last week" typed into a date column.

Identify the Non-Negotiable Records

Not all data is equally important to migrate cleanly. Calibration records tied to open or recently closed jobs, technician certification histories going back through the current recertification cycle, and any data referenced in an active client contract or ongoing litigation hold are non-negotiable — they need to move with full fidelity, not a summary. Older job history from a decade ago, by contrast, can often be archived as read-only PDF exports rather than fully re-keyed into the new system's live database.

Step Two: Clean Before You Migrate, Not After

A rule that saves companies weeks of pain: never migrate dirty data and plan to clean it up "later" in the new system. Later never comes, and now the mess lives inside a system that's supposed to be the trusted source of truth. Before migration:

• Standardize date formats and technician name spellings across every source file (the same tech listed as "Bob Smith," "R. Smith," and "Robert Smith Jr." in three sheets will become three different technician records unless you fix it first).
• Reconcile duplicate client and equipment records — merge the four rows for "Valero Port Arthur" and "Valero — Port Arthur Refinery" into one canonical client entry.
• Flag and resolve any calibration or certification records with missing dates rather than guessing on import; a wrong recertification date in the new system is worse than a gap that's flagged for follow-up.
• Decide on unit consistency (mils vs. thousandths of an inch, metric vs. imperial thickness readings) before data crosses into a system that will treat every number as authoritative.

Step Three: Map Fields, Don't Assume They Match

Spreadsheets tend to have ad hoc columns that grew organically — "Notes," "Status," "Misc" — that don't map cleanly onto a structured ERP schema. Before import, build an explicit field map: which spreadsheet column becomes which ERP field, and what happens to the columns that don't have an obvious home. A common mistake is letting free-text "Notes" columns simply vanish during import because nobody assigned them a destination — and six months later someone needs the context that was quietly dropped. Better to migrate anything ambiguous into a general notes field on the record than to lose it.

Step Four: Run a Parallel Period Before Full Cutover

Never flip a switch on a Friday and expect Monday to work. The safer pattern is a defined parallel-run period — typically two to four weeks — where technicians and office staff enter new jobs and calibration events into both the old spreadsheet system and the new ERP simultaneously. This does two things: it surfaces workflow gaps in the new system while the old system is still the safety net, and it gives you a clean way to validate that historical data imported correctly by cross-checking a sample of records against the source spreadsheets. Pick jobs and technicians from different service lines — UT, RT, MT, PT — for the validation sample, since import mapping errors often show up in only one data type.

What Companies Get Wrong: Common Migration Pitfalls

Losing Calibration Traceability

The single most damaging migration mistake is breaking the link between a historical job report and the calibration record that supported it. If a client asks for the calibration certificate behind a UT reading from fourteen months ago and the new system can't produce it because the migration only carried over "calibration due dates" going forward, not historical calibration events, you have a quality system gap that can surface in an ISO 9001 or client audit at the worst possible time.

Treating Certification Records as a Snapshot Instead of a History

Spreadsheets often only show a technician's current certification level and expiration date. A proper migration needs to preserve the full certification history — prior levels, recertification dates, method-by-method qualification — because that history is what proves continuous qualification if a client or code authority ever questions whether a technician was properly certified on the date a specific job was performed.

Underestimating Training Time

The technical migration is often easier than the human one. Office staff and field technicians who have used the same spreadsheet workflow for years will route around a new system if it's not clearly faster for their specific daily tasks. Budget real training time — not a one-hour webinar — and identify an internal champion on both the office and field sides who can answer day-to-day questions during the first month.

No Rollback Plan

Even a well-planned migration can hit a blocking issue mid-cutover. Keep the old spreadsheet system fully intact and accessible (not deleted, not archived to a drive nobody can find) for at least one full quarter after cutover, so there's a clean fallback if a critical gap surfaces after go-live.

What a Modern NDT ERP Should Do With That Data Once It's In

Migration isn't the finish line — it's what unlocks the reason companies migrate in the first place. Once historical data lives in a structured system, calibration due dates can trigger automatic alerts before equipment goes out of tolerance, technician certification expirations can block dispatch automatically rather than relying on someone remembering, and job costing can roll up in real time instead of at month-end. Reporting that used to require manually pulling and combining three spreadsheets — say, "show me every UT job for this client in the last two years with the technician and calibration record attached" — becomes a query that runs in seconds. That's the difference between data that exists and data that's actually usable, and it's the return on the migration effort.

A Practical Migration Timeline

• Weeks 1-2: Full data audit and inventory of every spreadsheet, log, and record source.
• Weeks 3-4: Data cleaning — standardize formats, merge duplicates, flag gaps.
• Week 5: Field mapping between spreadsheet columns and ERP schema, with explicit decisions on every ambiguous column.
• Weeks 6-7: Test import into a staging environment, validate against source data sample by service line.
• Weeks 8-11: Parallel run — both systems live, staff trained, discrepancies logged and resolved.
• Week 12: Full cutover, old system retained read-only as fallback.

Companies migrating from spreadsheets into a purpose-built inspection management ERP don't need to do this alone — a structured onboarding process, paired with ASNT Level III consulting on how the new system should encode your specific quality procedures, turns a risky data migration into a controlled upgrade. And once the historical record lives in a structured system, it becomes the foundation for far more — including feeding asset history into a digital twin platform for clients who want inspection data visualized against the physical asset over time.

Handling Special Cases: Radiography Source Logs and Client-Owned Data

Migrating Source Utilization and License Records

Companies running radiography under an NRC or Agreement State materials license carry a separate category of historical data that needs particularly careful handling during migration: source utilization logs, leak test records, and device inventory history tied to license conditions. These records often exist in a format dictated by the license itself rather than by the company's own preference, and a migration that reformats them without preserving the exact fields a license inspector expects to see can create a compliance gap that has nothing to do with the ERP system's general capability and everything to do with how the migration was executed. Treat these as a distinct migration workstream with its own validation pass, ideally reviewed by whoever holds Radiation Safety Officer responsibility before the old logs are retired from active use.

Client-Owned Historical Reports

Some client contracts specify that inspection records and reports are considered client property, with the contractor obligated to retain and produce them on request for a defined retention period — sometimes seven years, sometimes the life of the asset. When migrating historical job data, flag which records fall under this kind of contractual retention obligation, since losing or degrading fidelity on those specific records carries contractual risk beyond general operational inconvenience. It's worth cross-referencing active contracts against the migration plan before finalizing what gets fully migrated versus archived as a read-only export.

Choosing Between a Big-Bang Migration and a Phased Approach

Not every company needs the full twelve-week phased timeline described above — the right pace depends on company size and data complexity. A small shop with a handful of technicians and a few years of relatively clean spreadsheet history might reasonably compress this into four to six weeks. A larger multi-crew operation with a decade of mixed-format records, multiple service lines, and several active client contracts with specific retention terms should expect the fuller timeline, and attempting to compress it usually just moves the cleanup work from before go-live to after — which is a worse place for it to happen, because by then the bad data is already inside the system people are relying on daily.

Signs a Company Is Rushing the Migration

• Data cleaning is happening simultaneously with import rather than before it, because "we'll fix it once it's in the new system."
• No one has actually opened and reviewed a sample of migrated calibration records against the original source to confirm they match.
• The parallel-run period is being skipped or compressed to "just a few days" because staff are eager to stop maintaining two systems.
• Field technicians weren't consulted on the new mobile workflow before go-live and are encountering it live on a job for the first time.

Any one of these is a signal to slow down. A migration that takes an extra month but preserves clean, traceable historical data is a far better outcome than a fast migration that quietly breaks the audit trail a company spent years building.

Working With a Vendor or Consultant During Migration

Most ERP vendors offer some level of migration support, but the depth varies enormously — some provide a generic import template and leave data cleaning entirely to the customer, while others offer hands-on data mapping and validation support as part of onboarding. Before committing to a vendor, get specific about what migration support is actually included: will the vendor's team review a sample of migrated calibration and certification records for accuracy, or is that entirely the customer's responsibility? Companies without in-house expertise in structuring quality records for migration often benefit from outside ASNT Level III consulting support specifically for the data validation phase — someone who knows what a complete, audit-ready calibration record actually needs to contain can catch gaps that a general IT migration specialist, unfamiliar with NDT-specific compliance requirements, would likely miss entirely.

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.