Moving scanners does not have to cost you your triage history, but it will if you assume the new tool handles it for you. Six common beliefs get teams into trouble. Each one has a plain correction, and most come down to treating decisions as data you own rather than a feature you rent.
Myth 1: The new scanner will just import it
Fact: Import support varies widely. Some tools read a documented format, some offer an API, some offer nothing. Even when an import exists, it may drop dates, authors or comments. Ask, test with a sample, and plan for gaps.
Myth 2: Open findings are the history
Fact: Open findings can be regenerated by any scanner in minutes. The history is the closed and dismissed decisions, with reasons, owners and dates. Exporting only the open list keeps the cheap part and loses the valuable part.
Myth 3: Old suppressions are all still valid
Fact: Suppressions age. Components change, code moves and owners leave. Bulk importing years of exceptions carries stale assumptions into a tool that will treat them as current. Filter by reason, owner, age and existence, and give the survivors a review date.
Myth 4: Standards make decisions portable automatically
Fact: Standards help, but they are partial. SARIF can carry a suppression status and justification, and VEX formats can carry a status and a reason, yet neither standardizes the decider or an expiry. Portability improves when you use a standard and keep a sidecar for the rest.
| Need | Standard format alone | Needs a sidecar |
|---|---|---|
| Status and reason | Often yes | No |
| Decider | Rarely | Yes |
| Decision date | Sometimes | Often |
| Expiry | No | Yes |
| Ticket link | Rarely | Yes |
Myth 5: Matching is a solved problem
Fact: Two scanners can disagree about advisory IDs, affected ranges and package names. The OSV schema's alias mechanism exists because one vulnerability often has several identifiers. Expect an orphan list after import and treat it as a diagnostic, not noise.
Myth 6: Once imported, we can delete the old data
Fact: Keep an archived export for at least one audit cycle, and longer if your own obligations require. It is the evidence of what was decided before the move. Check retention rules with your compliance lead.
What the myths have in common
Each treats the migration as a tool event. It is a data and process event. The tool is the easy part. What takes the time is deciding what history is, mapping it to the new structure and proving it arrived intact.
A short readiness test
You are in decent shape if you can answer yes to these.
- We know which fields make up a decision record.
- We have a translation table for reasons.
- We keep original dates and deciders.
- We have a rule for which suppressions to import.
- We have an archive plan for the old export.
If any answer is no, that is the next task.
Quick check
Which myth costs teams the most?
The first. Assuming import works leads to discovering missing fields after the old contract has ended.
Is it ever fine to start from zero?
For small teams with few decisions, yes. Re-triage is cheap, and a clean start can be healthier than copying stale exceptions.
Sources
Last reviewed: 19 October 2026.
