Run the old and new scanner side by side for two to four weeks in report only mode, align inputs and scope, reconcile a sample of differences, restate your baseline on the new tool, and only then switch the gate. Skipping the parallel period turns a tool change into an unexplained jump in your numbers.
Why a parallel period
A new scanner will report a different total, even on the same repository. If you cut over without overlap, the next dashboard shows a drop or a spike and nobody can tell whether risk changed or counting changed. A parallel run gives you a bridge between the two series.
Plan the period
- Write the exit criteria first. For example: the new tool finds every confirmed issue the old one did on our sample, and we can explain at least 90 percent of the remaining differences. Pick numbers you can defend.
- Choose a sample of repositories. Include each ecosystem you use and at least one repository that is awkward, such as a monorepo or one with vendored code.
- Run the new tool in report only mode. It must not block merges during the overlap.
- Pin the inputs. Both tools read the same lockfiles and commit. The npm audit documentation notes that results can change on every run if the tree is rebuilt, so unpinned inputs ruin the comparison.
- Align scope. Decide whether development dependencies count, and set both tools the same way.
Reconcile a sample
Pick 30 to 50 differences and sort each one by cause: counting unit, scope, name format, version range, data timing, or a real coverage gap. The OSV schema is a good reference when you need to read an advisory's affected and fixed fields.
| Cause | Typical action |
|---|---|
| Counting unit | Convert to a shared unit |
| Scope | Align the setting |
| Name format | Normalize before comparing |
| Version range | Read the advisory, record the decision |
| Data timing | Wait a day and recheck |
| Real gap in the new tool | Note it, ask the vendor, decide if acceptable |
| Real gap in the old tool | Count it as a benefit of the switch |
Restate the baseline
Take the old tool's historical figures and recompute what you can on the new basis for the same date. If that is not possible, draw a break on the trend chart with a label. Tell stakeholders in advance, with the one page explanation of the unit and scope change.
Move the decisions
Your accepted risks and suppressions live in the old tool. Export them to a shared decision record, then regenerate the new tool's ignore configuration from it. Carry over expiry dates. Otherwise old decisions disappear and findings you already judged will resurface.
Cut over in stages
Switch the report first, then the pull request comment, then the blocking gate. Keep the old tool running in read only mode for one more cycle, so you can compare if something looks wrong. Remove it only after the exit criteria have held for a full release cycle.
What can go wrong
Teams often forget the integrations: ticket creation, chat alerts, and dashboards read by other departments. List them before you start. Also check whether the new tool covers every ecosystem your old one did, including build files you rarely touch.
Where Safeguard fits
Safeguard offers SBOM generation and dependency scanning with reachability analysis, and a free scan at gold.safeguard.sh/scan is a low effort way to compare its output against your current tool on one repository during a trial.
Quick check
How long should the parallel period last?
Two to four weeks usually covers normal dependency churn. Extend it if your release cycle is longer.
Should the new tool block merges during the overlap?
No. Run it in report only mode until your exit criteria are met.
Sources
Last reviewed: 19 October 2026.
