Most inspection software evaluations score vendors on features, price, and references. Migration usually gets one row on the spreadsheet: "can import historical data, yes or no." Every vendor answers yes. That row tells you nothing, and it is the row most likely to decide whether the project succeeds.
Migration is where programs stall, budgets slip, and audit trails quietly break. It deserves its own scorecard. Here is one that evaluation committees can use as written or adapt.
The five criteria that separate vendors
- Identity mapping as a deliverable. Ask each vendor how equipment and CML identities from your legacy sources get mapped to their model. The strong answer is a reviewed crosswalk document that your engineers sign off on before any data loads. The weak answer is "our import tool matches on name."
- Provenance retention. After migration, pick any historical thickness reading and ask the vendor to show where it came from. If the system can display the source file, the report page, or the original record, provenance survived. If the answer is "it came from the import," it did not.
- Staging before commitment. Good migrations load into a staging area, run validation, surface exceptions for human review, and only then commit to the system of record. Ask to see the exception report from a real migration, with customer identifiers removed.
- Unit and context handling. Legacy readings arrive in mixed units, with and without temperature compensation, from instruments of varying pedigree. Ask how the vendor detects and resolves these, and what happens to readings that cannot be resolved. "We convert everything" is not an answer; "unresolvable readings are flagged and excluded from rate calculations until reviewed" is.
- Who does the work, and who owns the result. Clarify whether migration is performed by the vendor, a partner, or your team, and what the handoff artifacts are. Then confirm in writing that migrated data, and all data you create afterward, exports in open formats if you ever leave.
How to weight the scorecard
Score each criterion one to five, with written evidence required for anything above a three. A demo claim is a three at best. A reviewed artifact from a comparable migration, or a live walkthrough against a sample of your own data, earns higher.
Weight provenance and identity mapping highest. Those two determine whether your corrosion rates remain defensible after the move. Staging and unit handling protect the schedule. Ownership protects you five years from now.
Run a paid pilot migration if you can
The single most revealing exercise is a small, paid migration of one unit's history before contract signature. Give each finalist the same messy sample: a spreadsheet with local naming conventions, a scanned report, a handful of readings with missing units. What comes back tells you more than any RFP response.
Watch for three things in the result: how many exceptions were surfaced rather than silently resolved, whether the crosswalk was presented for your review, and whether every loaded value traces to its source. A vendor that surfaces problems in a pilot will surface them in production. A vendor that returns a clean-looking dataset with no exceptions either got lucky or buried the problems.
The questions behind the questions
Migration quality is a proxy for how a vendor thinks about your data generally. A platform that preserves provenance during import will usually preserve it during daily use. A vendor that treats migration as a sales obstacle will treat data quality the same way after go-live.
At intelliSPEC we ask customers to hold us to this same scorecard, including the pilot. Whatever platform you choose, insist on seeing the evidence before you sign, not after.
