Replace a legacy scanner by running the new one in parallel, comparing results asset by asset, porting your policies and integrations, and archiving the old evidence before you switch off anything. Rushing the cutover is the usual mistake. A gap in coverage often goes unnoticed for months.
Inventory what the old scanner actually does
Write down every job it performs, including the quiet ones: scheduled scans, ticket creation, report emails to an auditor, a gate in the build. Teams often discover a duty nobody remembered only after the old tool is off.
Run both and compare by asset
For each asset, compare findings from both tools. Group differences into three: new tool finds more (check for false positives), old tool finds more (check for coverage gaps), same finding with different severity (check data sources). Do this on a sample, then widen.
Port policy and exceptions
Export accepted risks and suppressions from the old tool. Re-create them with expiry dates. A suppression carried over without review can hide a live issue for years.
Rebuild integrations
List each integration: tracker, chat, SSO, build pipeline, SIEM export. Confirm the new tool has an equivalent and test with a real item end to end. Check the API for anything you automated yourself.
Keep the evidence
Auditors may ask for scan history covering a past period. Export reports from the old system before the licence ends, and store them where the compliance team can find them. Check retention requirements with them first.
Cut over in stages
Move one team, then a group, then the rest. Keep the old scanner read only for one more cycle. Switch it off only after a full cycle shows no surprises.
When to stay put
If the old scanner meets your needs and the pain is process, a new tool will not fix it. Fix the process first, then judge the tool.
Communicate early. Developers who see new findings, new comments in pull requests and new ticket formats will assume something is broken unless told. A short note explaining what changes, when, and who to ask saves a week of questions and avoids workarounds that bypass the new tool.
Where Safeguard fits
Safeguard covers SBOM and dependency scanning, reachability analysis, policies and gates, and fix pull requests that stay off until you turn them on. You can try a free scan on a repository before you commit to anything.
Try it yourself
Watch how scheduled rescans surface a new finding, and think about which of your old scanner's scheduled jobs this would replace.
Click through it at your own pace, or open it full screen.
Quick check
How long should the parallel run last?
At least one full release or patch cycle, so scheduled jobs and exceptions are exercised.
What do I lose most often?
Suppressions and scheduled reports. Inventory both before you start.
Last reviewed: 19 October 2026.
