Export everything before you cancel: results, suppressions with reasons, rule customisations and audit records. Then run both tools in parallel for a few weeks, map old dismissals to the new tool, create a fresh baseline, and keep the old history readable. Do not turn the old tool off until the new one gates pull requests.
What you actually own
Before planning, list what the old tool holds that matters to you.
- Open findings and their status.
- Suppressions and the reasons given for them.
- Accepted risk records, with approvers and dates.
- Custom rules and rule settings.
- Policy settings, such as what blocks a merge.
- Historical scan results used as audit evidence.
The standard output format SARIF has places for several of these, including suppressions and result fingerprints. Whether a vendor exports them is a question to ask, and it is better asked before signing than after.
Plan in six steps
1. Export. Pull results, suppressions and rules. Check that the export opens and holds the reasons, not just IDs. Store it somewhere durable, because evidence from last year may be asked for next year.
2. Map rules. Rule names will not match. Build a rough table: old rule, equivalent new rule, none. Rules with no equivalent are coverage you may lose, and rules the new tool has that the old did not are findings you will newly see.
3. Run in parallel. For two to four weeks, run both. Compare results on the same repositories. Expect differences in both directions. Label a sample of the differences to learn which tool is right more often.
4. Re-baseline. The new tool will report a different set of existing findings. Create a baseline in the new tool so pull requests are judged on new code only, as described in our baselining guide.
5. Carry over dismissals thoughtfully. A suppression that said not exploitable in the old tool may not apply to the new finding, since it is a different result. Re-review the high severity ones and carry over the rest in bulk with a note.
6. Cut over. Switch the required pull request check to the new tool, keep the old one scanning nightly for a short period, then retire it.
Things that bite
- Path based matching: moving to a new tool changes how findings are fingerprinted, so everything looks new once.
- Branch protection: required status check names change. Update them or merges will stall, or worse, pass without a check.
- Tokens and integrations: remove credentials issued to the old vendor, and revoke repository access.
- Contract terms: check data deletion and export clauses. You may need written confirmation that your code and results were deleted.
Communicate
Tell developers what changes, when, and what will look different. Run a short session on the new messages and how to dismiss a finding. Expect a noise spike in the first week and say so.
When not to switch
If your pain is noise, try tuning, baselining and rule review first. If your pain is missing language coverage or a build that cannot be scanned, switching may be right. Decide with pilot evidence, not frustration.
Quick check
How long should both tools run together?
Two to four weeks is typical, long enough to compare real pull requests and label a sample of differences.
Do suppressions carry over automatically?
Rarely. Treat them as a list to re-review, with the high severity ones checked by a person.
Safeguard's CLI can output SARIF and its free scan at gold.safeguard.sh/scan can run alongside your existing tools.
Sources
Last reviewed: 19 October 2026.
