Before cutting over to a new scanner, list every place the old one is connected, copy out the evidence you must keep, rebuild the reports others rely on, and revoke the old tool's access only after the new one is proven. The risk in a migration is not the install, but the things nobody remembered.
1. Inventory the connections
Search for where the old tool touches your systems:
- CI jobs and pipeline templates, including shared libraries.
- Source control apps, webhooks and status checks that branch protection requires.
- Ticketing and chat integrations.
- Registry and artifact store access.
- Scheduled scans and the owners of each schedule.
- Dashboards and email digests people read.
- API users, scripts and exports others built on top.
Ask each team lead to confirm. Hidden consumers, such as a quarterly report built by finance or a customer portal feed, are common.
2. Preserve what you must keep
- Historic findings and triage decisions, with who decided and when.
- Accepted risks and their expiry dates.
- Past SBOMs for released versions.
- Audit evidence that the control ran, by period.
- Exception approvals.
Export in an open format where possible and store it somewhere with the same retention rules as your other audit records. Read your contract for export terms before the end date, not after.
3. Map policy and rules
Translate gating rules one by one: severity thresholds, license rules, blocked packages, exclusions. Do not assume equal names mean equal behaviour. Test each rule with a known case.
4. Run in parallel
Keep both tools for at least one full release cycle. Compare results as in why scanners disagree, and see the detailed parallel run and cutover steps. Make the new tool report-only first, then promote it to blocking.
5. Rebuild reports
List each report, its audience and frequency. Recreate the important ones, retire the rest on purpose, and tell the audience the numbers will change and why.
6. Clean up access
After cutover:
- Revoke tokens, API keys and app installations belonging to the old tool.
- Remove it from branch protection requirements, or required checks will block merges.
- Delete or archive data according to your retention policy and ask the vendor to confirm deletion where contracts allow.
- Remove old pipeline steps so nobody wonders if they still matter.
7. Confirm coverage
Compare the list of repositories scanned before and after. Any repository missing from the new tool's inventory is now unchecked. A short script comparing both lists takes an hour and prevents a silent gap.
8. Communicate
Send developers a note on what changed, where results live and who to ask. Update internal documentation and onboarding material.
Where Safeguard fits: SBOM and dependency scanning plus policies and gates cover the scanning and rule layers, and the free scan is a way to check the new output before you plan a cutover.
Quick check
When should the old scanner be switched off?
After the new one has covered a full release cycle, matched or explained differences and carried every required check.
Last reviewed: 19 October 2026.
