Audit a CSV Migration With One Paste

CSV migrations have a special talent for looking boring right up until they hurt you.

You export 500 records from one system. You clean the columns. You rename fields. You split a full name. You normalize statuses. You import the result into the new system. The preview screen says the file is valid.

The file can be valid and still be wrong.

CSV validation usually checks whether the rows parse, whether the headers exist, and whether the columns have acceptable types. It does not tell you whether the same transformation logic was applied to every row.

That is the part that breaks migrations quietly.

The real risk in CSV migration

Most migration mistakes are not dramatic syntax errors. They are small inconsistencies:

• one row keeps whitespace that every other row trimmed;
• one status value is mapped differently;
• one name is split at the wrong space;
• one date changes from ISO format to local format;
• one empty value becomes an empty string instead of null;
• one column is copied from the wrong source field.

If you are migrating ten rows, you can inspect them. If you are migrating 500 rows, inspection turns into sampling. Sampling turns into hope.

The better question is: can the migrated file be explained by one rule?

If row 1 becomes the target format by renaming email_address to email, trimming name, and mapping Y to true, then row 500 should follow that same rule. If it does not, you want to know before the import.

A one-paste audit workflow

Latentmachine Verify is built for this kind of audit.

Paste the original export on the left. Paste the migrated output on the right. The files can be JSON or CSV, and the two sides do not have to use the same format. If your source is CSV and your transformed output is JSON, that is fine. If both are CSV, that is fine too.

Verify lines up the records by row, infers the majority transformation rule, and applies that rule to every original row. Any transformed row that differs from the predicted output is flagged.

The result is not just "pass" or "fail." You see:

• how many rows were checked;
• whether the batch is consistent;
• the inferred rule steps;
• the exact rows that break the rule;
• the predicted output versus the actual migrated output.

That gives you a migration audit you can act on.

It also keeps the review focused. Instead of asking someone to re-open a 500-row spreadsheet and inspect everything manually, you can hand them the small set of rows where the migrated output disagrees with the rule. That is a much better use of human attention. People are good at judging edge cases once the suspicious rows are isolated. They are not good at visually detecting one inconsistent pattern in a wall of nearly identical records.

Example: the one wrong status

Suppose the original CSV has:

id,name,status
1,Ana Meyer,A
2,Bo Singh,A
3,Cleo Park,I

And the migrated output has:

user_id,display_name,state
1,Ana Meyer,active
2,Bo Singh,enabled
3,Cleo Park,inactive

The file parses. The headers are correct. The rows look plausible.

But the status mapping is inconsistent. If A maps to active, row 2 should not say enabled. Verify flags that row and shows what the majority rule predicted.

That is the important migration distinction: plausible values are not enough. The output must be generated by the same rule.

Why this catches what scripts miss

If you wrote the migration script yourself, you might think the script is already the rule. In many cases, yes. But migration output can still drift:

• someone manually edited a few rows after export;
• a spreadsheet formula was dragged over the wrong range;
• a later cleanup step touched only part of the file;
• an upstream export included a variant you did not test;
• an LLM helped rewrite some records manually;
• the script changed between test and final run.

Verify audits the actual output, not your intention and not your script. That makes it useful even when the migration pipeline has multiple steps.

What to do with flagged rows

Flagged rows are not automatically "bad." They are rows that do not match the inferred majority rule. Sometimes the row is genuinely wrong. Sometimes the row represents a real edge case that needs its own rule.

Either way, the audit has done its job. It found the rows that deserve attention.

If the flagged row is wrong, fix the output or rerun the migration. If the flagged row is a legitimate edge case, add an example in the Infer and make sure the rule you actually want covers it. The goal is not to force every row into sameness. The goal is to separate real edge cases from accidental inconsistency.

Before the import button

The safest time to catch migration drift is after generating the output and before importing it into the target system.

At that moment, you still have both sides: the original export and the transformed file. You can paste them into Verify, download a report, fix the small set of suspicious rows, and only then import.

That is a much calmer workflow than discovering the issue inside the new system after relationships, IDs, and audit logs have already been created.

This is especially useful for migrations that happen in rounds. Run the audit on the test export. Run it again on the final export. Keep the downloaded report with the migration notes. If something changes between the two runs, you have a concrete artifact that shows whether the transformation stayed stable or whether the data itself introduced a new edge case.

CSV migrations do not need a huge QA process every time. They need one reliable habit:

Before you import, check whether every row followed the same rule.

Open Verify ->