How to verify a data conversion before you trust it

Every vendor tells you your data will "come over cleanly." Almost none of them tell you how to check. That's backwards: the whole point of a conversion is that you can trust the new system on day one, and trust is something you verify, not something you're promised.

This is the verification routine we use on our own conversions. It works no matter what system you're leaving or joining, and your own staff can run it — no consultant required.

The principle: reconcile, don't eyeball

Clicking around the new system and thinking "looks right" is not verification. Verification means running the same report in both systems and getting the same number. A conversion that's wrong is almost never wrong everywhere — it's wrong in a corner: one truncated field, one date format, one customer whose balance doesn't tie. Totals and counts find those corners fast.

Step 1: Count the records

Before anything else, count what went in and what came out. Run these in your old system (a report footer or a query usually gives you the count), then in the new one:

• Customers — active accounts
• Items / part numbers — the item master
• Vendors
• Open orders — order count, not just lines
• Order history — total historical orders and order lines
• Open purchase orders

The counts should match exactly, or the difference should be explainable line by line — voided orders deliberately excluded, test records skipped, an inactive-customer cutoff you agreed to. "Close" is not a result. If the conversion dropped 14 records, you want to know which 14 and why.

Step 2: Tie out the money

Counts prove the records made it. Balances prove the records are right. These five numbers catch most conversion errors, because a single mis-decoded money field anywhere in the data throws them off:

• Open order value — the total dollar value of open sales orders
• A/R open balance — total open receivables, and per-customer balances for your largest accounts
• A/P open balance — total open payables
• Open PO value — the committed purchasing dollars
• Inventory valuation — on-hand quantity × cost, if your old system tracks it

Legacy systems love to store money in ways that break naive conversions: amounts stored ×100 with no decimal point, packed fields, negative balances represented in odd ways. A balance that ties to the penny is strong evidence the converter decoded every one of those correctly. A balance that's off by a factor of 100 tells you exactly what went wrong.

Step 3: Spot-check the corners

Totals can hide offsetting errors, so finish with targeted spot-checks. Pick records you know cold — the customer you talk to every week, the part you've stocked for twenty years — and open them side by side:

• Your largest customer: address, terms, and open balance
• Your oldest open order: lines, quantities, prices, promise dates
• A part with history: cost, on-hand, and its transaction trail
• A customer part number: does the cross-reference still resolve to the right item?
• The weird one: every shop has a record that abuses the old system — the order with 200 lines, the customer with four ship-tos. Weird records are where conversions break. Check yours.

Step 4: Do it in a sandbox, before you commit

All of this should happen in a working sandbox — a real, running copy of the new system loaded with your converted data — before you've committed to anything. That's the order of operations that protects you: extract, convert, verify against your own reports, and only then pick a go-live date.

If a vendor wants you to sign first and see your data in their system later, that tells you something about how their conversions usually go.

It's the standard we hold our own conversions to: our conversion programs are AI-written and human-verified, and these tie-outs are the proof we hand you — not a substitute for your own checking, but a head start on it.

What you need from your old system

Any conversion — ours or anyone's — needs three things from the system you're leaving:

1. Access to the raw data — the actual files or database, not just the app's screens
2. A way to export it — to CSV, Excel, or any flat format
3. The table layouts — what's in each table and what the field names mean

If you can produce those three, your data can move. If you're not sure your system can produce them, that's exactly the kind of question we answer for free — tell us what you run and we'll tell you what it involves.