Compare six numbers captured the day before and a month after cutover: open findings by severity, suppression rate, median age of open findings, reopen rate, mean time to remediate, and the share of findings with an owner. Large jumps in any of them point to an import problem, not a security improvement.
Why metrics matter after a move
A migration can look successful while quietly breaking the record. Everything imports, the dashboard loads, nobody complains. Then a quarter later the numbers are strange and nobody can say whether the change is real. Baseline numbers let you tell the difference.
The six metrics
| Metric | What it shows | A warning sign |
|---|---|---|
| Open findings by severity | Exposure | Big drop or spike on day one |
| Suppression rate | How much is hidden | Sharp fall means decisions were lost, sharp rise means over import |
| Median age of open findings | Backlog health | Reset to near zero means dates were lost |
| Reopen rate | Decision quality | Spike means imported decisions were wrong |
| Mean time to remediate | Process speed | Sudden improvement without a cause |
| Findings with an owner | Accountability | Fall means owner fields did not come across |
Capture these for the previous quarter, too. Trends tell more than single points.
Expect some movement, and explain it
The new scanner will find things the old one missed and miss some the old one found. So open counts will move. The point is to explain the movement, not to demand zero change. For each metric, write one paragraph of explanation: what changed, why, and how you know.
A useful habit is to split open findings into two groups, carried over from the old tool and first reported by the new one. Their ages and decision rates should differ, and reporting them separately avoids mixing a data artifact with a real change.
Add a coverage metric
Count the repositories scanned and the ecosystems read, before and after. A drop in either means less visibility, even if the finding counts look better. Cross check against a list of all repositories, not only the ones that appear in the tool.
Check decision quality directly
Sample a handful of findings dismissed after the migration and review them with the same standard you used for imported ones. If the quality of new decisions has dropped, perhaps because reasons are less clear in the new interface, you want to know early.
Reporting to leadership and auditors
Present the before and after table with explanations, the sample check results and the list of known gaps. This is more convincing than a statement that the migration went well, and it protects the team if a question comes up later.
A note on Safeguard
Safeguard provides reachability analysis and compliance and evidence automation, which can help explain why counts moved. You can run a free scan at gold.safeguard.sh/scan to get an independent baseline.
Try it yourself
Open the demo and look at how a vulnerability management view summarizes counts, ages and states. Those are the same views you will compare before and after.
Click through it at your own pace, or open it full screen.
Quick check
How soon after cutover should we measure?
Take a first reading in the first week to catch import errors, and a second at about 30 days for trends.
What if open findings drop sharply?
Do not celebrate yet. Check coverage and suppressions first, since a drop can mean the tool sees less.
Last reviewed: 19 October 2026.
