Carry the original first detected date into the new scanner as a separate field, and compute age and SLA from it. If the new tool cannot store it, keep a sidecar table keyed by package, version and advisory. Without it, every old finding looks brand new and your overdue count collapses to zero overnight.
Why the reset happens
Most scanners stamp a finding with the date it was first seen by that tool. Switch tools and every finding is "first seen" on cutover day. Reports that count days open, mean time to remediate, or SLA breaches will show a sudden miracle. Leadership may celebrate. An auditor will not.
The public schemas treat the date as first class data. The GitHub REST API for dependency alerts returns a created_at timestamp per alert, and the CycloneDX 1.6 analysis block has a firstIssued field. The idea is the same: a finding has a birth date that belongs to the vulnerability on your component, not to the tool.
Three places to keep the date
| Option | How it works | Trade off |
|---|---|---|
| Native field in the new tool | Import sets first detected | Cleanest, but not all tools allow it |
| Custom label or property | Store the date as a tag or custom attribute | Works, but reports may ignore it |
| Sidecar table | Spreadsheet or database keyed by component and advisory | Always possible, needs a join in reports |
Ask the new vendor early which of these they support. If the answer is "none", plan for the sidecar.
Steps
- Export created or first detected date for every open finding from the old tool. Also export it for findings fixed in the last 12 months, so closed trends stay intact.
- Build a key for each row: package identifier, version and advisory ID. Include advisory aliases, because the new tool may use a different primary ID.
- After the first scan in the new tool, join on the key and write the old date into whatever field you chose.
- Report the unmatched rows. These are findings the old tool had and the new one lacks, or the reverse, and both need a look.
- Freeze the sidecar after cutover. New findings use the new tool's own date.
Decide how SLA clocks should behave
Dates are a fact, but SLA treatment is policy. Some teams choose to restart clocks for old findings with a one time grace period, because the new tool surfaced items the old one missed. If you do that, write it down, set an end date for the grace period, and report the two populations separately.
A defensible pattern is: findings carried over keep their original date and original SLA; findings found only by the new scanner start their clock on the day the new scanner reported them. That treats discovery date honestly in both cases.
Check the numbers before and after
Pick three metrics, such as median open age, count over SLA, and mean time to remediate for the last quarter. Record them the day before cutover and the day after. They should barely move. A large jump means the dates were not carried or the join missed rows.
Try it yourself
Open the demo and watch how a monitored finding accumulates history over time. That running record is what you want to survive the switch.
Click through it at your own pace, or open it full screen.
Quick check
Should fixed findings keep their dates too?
Yes, for at least the last reporting period. Trend lines and remediation time metrics depend on them.
What if the old tool only shows scan date, not first detected?
Use the earliest scan in which the finding appeared. If that is unavailable, label the date as approximate in your records.
Sources
Last reviewed: 19 October 2026.
