ERP Implementation Timeline for NDT Companies: What 30-90 Days Actually Looks Like

Every NDT company owner who has shopped for an ERP system has heard some version of the same pitch: "You'll be live in 30 days." Some implementations land there. Most don't, and the ones that run past 90 days usually do so for predictable, avoidable reasons — not because the software failed. The gap between a five-technician UT shop running out of a single yard and a 60-person multi-method outfit running RT, PAUT, and TOFD crews across three regional offices with a decade-old accounting system explains most of the variance.

What follows is a realistic phase-by-phase picture of what a 30-90 day NDT ERP implementation looks like when it goes well, where the actual risk sits, and what pushes a project past that window. Treat every day range here as typical, not a guarantee — your timeline depends on data quality, team availability, and how many configuration decisions you show up ready to make.

Why "30-90 Days" Is a Range, Not a Number

The spread isn't vendor inconsistency — it's the compounding effect of a few variables: how many report templates you run (a UT-and-MT-only shop has a far lighter configuration lift than one running UT, RT, MT, PT, VT, PAUT, and TOFD), how clean your existing technician certification and calibration records are, whether you're integrating with QuickBooks Online or a customized Sage instance with years of chart-of-accounts drift, and how many locations go live at once. A single-site shop with decent records and a narrow method scope can realistically land in 30-45 days. A multi-site company with mixed legacy systems, heavy customization, and a full accounting integration is more realistically looking at 75-90+ days, assuming nothing surprises anyone along the way.

The Phase Breakdown: What 30-90 Days Actually Covers

A well-run implementation moves through these phases in roughly this order, with meaningful overlap between adjacent ones:

• Discovery and scoping (days 1-15). Mapping actual current-state workflows — job intake and quoting, scheduling and technician dispatch, field data capture, report review and sign-off, invoicing, and calibration/certification tracking — not the idealized version in the quality manual. Skipping this is the top cause of a project that goes live on schedule but needs months of rework afterward.
• Data migration planning (days 10-20, overlapping discovery). Mapping which fields in the old system map to which fields in the new one, what needs cleanup first, and what won't migrate — most companies bring over 2-3 years of active history and archive the rest as read-only reference.
• Configuration (days 15-45). Building report templates, job costing structure, approval workflows, user roles, and integrations. Timelines here are driven by decisions your team needs to make, not software limits.
• Data migration execution (days 30-55). Usually two passes: a bulk load of historical records into a test environment for validation, then a final delta pass closer to go-live to catch anything changed since, especially active jobs and certification updates.
• Integration testing (days 45-60). Every integration point — accounting sync, any retained scheduling tool, mobile data capture, e-signature — tested against real transaction types, not demo records.
• User training (days 50-70). Role-specific tracks for office/admin staff, field technicians, and Level III/quality reviewers, not one all-hands demo.
• Parallel run or phased cutover (days 60-85). The window where the company decides how much old/new overlap it can tolerate — detailed below.
• Go-live (typically day 75-90). The date the new system becomes the system of record. What precedes it matters more than the date itself.
• Post-go-live stabilization (days 90-120+). A support period, not a single event — covered in its own section below.

Data Migration: Where NDT-Specific Risk Actually Lives

Generic ERP migration advice treats data migration as an IT exercise: move the records, check the counts match, move on. For an NDT company, several data categories carry compliance and safety weight a generic checklist won't catch.

• Technician certification records and expiration dates. The single highest-risk migration item. If an ASNT SNT-TC-1A Level II certification expiration date gets transposed or dropped during migration, the new system can show a technician as "current" when they're actually expired — and a scheduler working off that record could assign them, or a Level III could sign off on work performed by someone who shouldn't have been on that method unsupervised. Every certification record needs a manual spot-check against the physical certificate after migration, not just an automated row count.
• Equipment and calibration records with due dates. Same risk profile. A UT flaw detector, a phased array unit, or a calibration block set that migrates with a wrong or missing next-due date can end up dispatched on a job past its calibration interval, unnoticed until an auditor asks for the certificate.
• Historical job and client records. Lower compliance risk, higher relationship risk — contact history, prior scope, and pricing history need to carry over cleanly enough that account managers aren't starting from zero with long-standing clients.
• Active jobs in progress. A turnaround job that starts under the old system and is still open on go-live day can't simply "cut over." The realistic approach: finish active jobs in the old system through invoicing, start anything opened after a defined cutoff date in the new one, and track a short list of "straddle" jobs manually until they close.

Configuration Decisions That Quietly Set the Timeline

Four configuration areas move the calendar more than anything else, and all four are your team's decisions, not the vendor's.

• Report templates. UT, RT, MT, PT, VT, PAUT, and TOFD each carry different data fields — a UT thickness report needs scan grid data, a PAUT report needs probe/wedge configuration and encoder scan data, an RT report needs exposure parameters and source-to-film distance, an MT/PT report needs surface prep and contrast data. A company running all seven methods with client-specific variants can easily be building or migrating 10-15+ templates and getting each approved against the quality manual — usually the single largest configuration line item.
• Job costing structure. How labor hours, equipment day-rates, and consumables (couplant, film, penetrant/developer, replacement probes) roll up into job profitability is a decision, not a default. Get it wrong and profitability reporting is meaningless from day one.
• Approval workflows. Who signs off on what and in what order — a Level II technician drafts a report, a Level III reviews and approves before it reaches the client — needs to be built into workflow logic, not left as an informal office habit the software doesn't enforce.
• Integrations. Accounting software (QuickBooks or Sage are the two most common here) and any retained scheduling tool both need defined integration points. A clean QuickBooks Online sync can be configured and tested in days; a heavily customized on-premise Sage instance with years of chart-of-accounts drift can add weeks.

Parallel Run vs. Hard Cutover

This is the highest-stakes operational decision in the project, and it's a genuine tradeoff, not a right-versus-wrong call. Running old and new systems side by side for a full pay period or two catches discrepancies — a job that invoiced differently, a calibration date that migrated wrong, hours that didn't roll up correctly — before they become client-facing problems or payroll errors. The cost is real: double data entry for office staff, and a stretch where field crews could be getting instructions from two systems that disagree. For a company mid-turnaround season where downtime isn't an option, a short parallel run limited to non-critical functions (invoicing and job costing) while dispatch and reporting cut over immediately is a common middle ground.

A hard cutover on a single date is faster and avoids the double-entry burden, but concentrates all risk into one day — if migrated data is wrong or a workflow got missed in scoping, you find out live, with clients waiting on reports and crews waiting on schedules. Companies that pull off a hard cutover successfully are almost always the ones with the narrowest configuration scope, the cleanest legacy data, and a go-live date deliberately scheduled outside their busiest turnaround window.

Getting Field Technicians to Actually Adopt the New System

NDT technicians are rigorously trained on inspection methods and often genuinely skeptical of office software — particularly techs who've run a system they know cold for a decade, or who are more comfortable with a clipboard than a tablet. Software that adds friction to the actual inspection work gets worked around, not adopted, and a workaround culture defeats the point of the switch. A few tactics consistently beat a mandatory all-hands rollout announcement:

• Involve two or three respected senior technicians early — during configuration and template design, not just training. A senior UT tech with a hand in the mobile report layout becomes an internal advocate instead of the loudest skeptic.
• Start with one crew or one region rather than flipping the whole field force over on the same day, so rough edges in mobile data entry get fixed on a small group first.
• Keep mobile data entry genuinely simple. If logging a UT reading takes more taps than writing it on a clipboard, adoption lags no matter how good the training was — build field-facing screens for someone in gloves at a scaffold, not someone at a desk.
• Don't pull paper away before trust is built. A short, quietly tolerated paper-backup period removes the highest-anxiety objection without undermining the cutover.

Go-Live Readiness and the First 30 Days After

Before committing to a go-live date, confirm each of the following — treat any "no" as a reason to slip the date, not to go live and fix it after:

• Migrated data validated against source records, with certification and calibration dates specifically spot-checked, not just row-counted
• All user groups trained and credentialed in the new system with correct role-based permissions active
• Every report template approved against the company's quality manual and any client-specific requirements
• All active technician certifications and equipment calibration due dates confirmed current as of go-live date
• Approval and sign-off workflows tested end to end with a real, not sample, report
• A written rollback or contingency plan: who decides to delay or revert, what triggers that decision, and how in-flight jobs get handled if go-live is paused

Then treat go-live as the start of a stabilization period, not the finish line. The first month after cutover reliably surfaces things nobody scoped — an unusual report type for a client with a niche requirement, a workflow edge case like a partial re-inspection handed to a different technician mid-report, or a reporting quirk that only shows up once real invoicing volume runs through the new costing structure. Budget dedicated support time for this window, whether that's a vendor support period, an internal super-user on call, or both — companies that skip it tend to accumulate a backlog of manual workarounds that quietly erode the value of the switch.

What Pushes an Implementation Past 90 Days

A handful of factors reliably extend timelines past the typical range, worth naming before committing to a schedule:

• Heavy customization requests beyond standard configuration — custom report layouts per client, non-standard costing logic, bespoke integrations — all add build and test time.
• Multiple locations or business units onboarding simultaneously multiplies discovery, training, and data validation work rather than simply adding to it, since each site often runs slightly different workflows under one company name.
• Messy or incomplete legacy data that needs cleanup before it can even be mapped — missing calibration histories, duplicate client records, inconsistent job numbering — adds weeks that rarely show up in the original plan.
• A complex existing accounting or ERP stack with heavy customization of its own turns a straightforward integration into a multi-week reconciliation project.
• Redesigning workflows and switching software at the same time. If your job-costing process, approval chain, or dispatch workflow is genuinely broken, fix it on paper first, then configure the new system to match. Inventing a new workflow and validating new software simultaneously makes every test-phase problem ambiguous — software or process? — and that ambiguity is what turns 90 days into 150.

Choosing Your Implementation Approach

Vendor-led, self-implemented, or hybrid isn't a one-size answer — it should follow from internal IT capacity, company size, and how complex current processes already are. Vendor-led implementation, where the provider's team runs discovery, configuration, and training, fits companies without dedicated internal IT staff, or any company running multiple methods and offices where the coordination burden alone justifies outside project management. Self-implementation — often a single operations manager plus a tech-savvy senior technician working from vendor documentation and support tickets — can work well for a smaller single-site shop with a narrow method scope and genuinely clean data, but it demands real internal time that's easy to underestimate against a live inspection schedule.

A hybrid model — vendor-led for data migration and integration, the highest-risk and most technical pieces, with internal ownership of training and workflow mapping, which require intimate knowledge of how crews actually work — is the most common pattern for mid-size companies and usually the best balance of cost, speed, and control. Whichever path you choose, the deciding factors stay the same: how much internal bandwidth you genuinely have during the window, how many methods and locations you're bringing online at once, and how much of your current process is undocumented tribal knowledge that needs capturing before anyone can configure around it.

None of this is a reason to delay switching off a spreadsheet-and-paper system that's already costing you missed calibration renewals or scheduling conflicts. It's a reason to walk in with realistic expectations, a phase-by-phase plan, and a go-live date you're willing to move if the readiness checklist says you're not there yet. Companies evaluating an Atlantis NDT ERP rollout, comparing NDT reporting software options, or bringing in outside ASNT Level III consulting to help scope the transition should expect this same general 30-90 day shape, with the same variables deciding where in that range they land.

Planning an ERP transition and want a realistic scope estimate for your specific method mix and site count rather than a generic sales number?

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.