Draw a sample of about 20 imported decisions across risk levels, open each in the new tool, and compare it with the old record on six points: identity, state, reason, comment, dates and owner. If more than one or two fail, stop and fix the import before running it on everything.
Why sample at all
You cannot read thousands of rows, but you can read twenty. A small, well chosen sample finds systematic errors quickly, such as a column shifted by one, dates replaced by the import day, or comments truncated. Errors that affect every record show up in any sample. Rare errors do not, which is why the sample is a gate for the import process, not a proof of perfection.
Choose the sample on purpose
Random alone can miss the interesting cases. Stratify:
| Group | Count | Why |
|---|---|---|
| Critical or high severity dismissals | 5 | Highest consequence |
| Accepted risk with owner and expiry | 4 | Audit exposure |
| Long comments or special characters | 3 | Truncation and encoding bugs |
| Oldest decisions | 3 | Date handling |
| Monorepo or multi project cases | 3 | Scope mapping |
| Random | 2 | Anything else |
Write down the chosen IDs before you look at results, so you cannot adjust the sample to suit the outcome.
The six checks
For each record, compare the old tool with the new one.
- Identity. Same package, version and advisory, or a documented alias.
- State. Dismissed stays dismissed, accepted stays accepted, deferred is open.
- Reason. Matches your translation table.
- Comment. Complete, readable, no cut off text or garbled characters.
- Dates. Original decision and first detected dates preserved.
- Owner. The real decider is visible, not the import account.
Score each record pass or fail per check. Keep the results in a simple sheet.
Decide what a pass means
Set the rule before you start. For example: no failures on identity or state, and no more than two failures overall in twenty. A failure on state is serious, because it means a finding is wrongly hidden or wrongly open. Treat any such failure as a stop.
When something fails
Do not patch individual records. Find the cause in the mapping or script, fix it, roll back the import for that project if the tool allows it, and run again with a fresh sample. Patching by hand hides the bug that will hit the next hundred records.
Repeat at scale
For the full import, repeat on a sample from each project group, or at least each ecosystem. A large import of mixed repositories can pass overall and still fail in one corner, such as a language whose package names are normalized differently.
Record the result
Save the sample list, the scores and the decision to proceed with the migration record. That sheet is the evidence an auditor or a future engineer will want when asking how you knew the import was good.
Quick check
Is 20 enough?
It is enough to catch systematic errors. For rare errors, add a sample per project group and review the orphan list.
Who should do the check?
Someone other than the person who wrote the import script, so mistakes in assumptions are caught.
Last reviewed: 19 October 2026.
