Your old scanner's history does not move itself. Export open findings, past decisions such as dismissals, and the reports you need for audits before access ends. Expect the new tool to start a fresh baseline. Keep the export in a place your team controls, with a note on what it contains.
What counts as history
- Open findings with their status and owner.
- Decisions: dismissals, accepted risks, false positive marks, and the reasons given.
- Historical scan results used for trend charts.
- Reports given to customers or auditors.
- Configuration: rules, policies and thresholds.
Each has a different value and a different lifespan.
Why it will not carry over cleanly
Tools identify a finding in their own way. GitHub's code scanning documentation, for example, explains that it matches results across runs using fingerprints, and that rule identifiers and file paths need to stay consistent for those fingerprints to remain stable. Another tool will use different identifiers, so a finding you already triaged looks new. That is why decisions need to be exported and re-applied deliberately. Our post on switching SAST tools without losing suppressions covers the mechanics for code findings.
What to keep, and for how long
| Item | Keep | Why |
|---|---|---|
| Decisions with reasons | Until the finding is gone | Prevents re-triage |
| Reports sent to customers | Per your contract and audit needs | Evidence |
| Trend data | Long enough for the review period you care about | Trend continuity |
| Raw scan output | Short term, then delete if allowed | Space and data minimization |
Check retention requirements in your own policies and contracts. Do not guess.
Before access ends
- Ask the vendor what export formats exist and how long data remains available after termination. See export formats to demand from a security scanner.
- Export in a standard format where possible, such as SARIF for code findings or an SBOM format for inventories.
- Store the export with a readme listing date, tool, version and scope.
- Ask for written confirmation that your data will be deleted after the agreed period. The clause is discussed in delete or return data at contract end.
Re-baseline on purpose
Expect the new tool to show a larger or different set of open issues at first. Record it as a baseline and track from that date, as in baselining a new scanner.
Sources
Quick check
Should we keep the old tool read only for a while?
If the contract allows it at a sensible cost, a short overlap after cutover is useful for lookups. Do not rely on it as your archive.
Do we need every old finding in the new tool?
No. Carry over open findings and decisions. Closed items belong in the archive.
Safeguard covers SBOM and dependency scanning, reachability analysis, policies and gates, and compliance evidence automation. You can try a free scan at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
