Migrate in five steps: export what you have, run both in parallel on a pilot group, move exceptions with their owners, switch gates last, then retire the scripts. Keep the old setup running until the new one has matched it for a full release cycle.
Step 1: Inventory what your scripts do
List every scan, schedule, gate and report. Include the quiet jobs, such as a monthly export someone sends to a manager. Anything not on the list will disappear in the migration.
Step 2: Export history and exceptions
Save scan results, suppression files, allowlists and ticket links in a neutral format. Gitleaks, for example, supports baseline reports and an ignore file by fingerprint, so you can carry known findings forward rather than reopening them.
Step 3: Run in parallel on a pilot
Choose two or three repositories from different teams. Run both setups. Compare findings, and write down every difference with the likely cause: data source, version matching, scope.
Step 4: Move gates last
Run the new scanner in report just mode first. Switch the merge gate once developers have seen its results for a few weeks and trust them.
Step 5: Retire carefully
Disable old jobs one at a time, keep their configuration archived, and watch for a month. Check that nobody relied on a report you forgot.
Migration checklist
- Owners assigned for each exception
- Expiry dates preserved or reset
- Developer notice sent before the gate changes
- Rollback path documented
- Evidence from the old setup kept for your audit period
What to avoid
Do not migrate everything in one weekend, and do not turn on blocking gates on day one. A migration that breaks the build teaches developers to distrust the new tool.
Safeguard covers this ground with SBOM and dependency scanning, reachability analysis, policies and gates, and compliance evidence automation. Autonomous fix PRs are off by default, with every category set to Manual. You can try a free scan at gold.safeguard.sh/scan.
Communicating with developers
Tell developers what is changing, when, and what they need to do, which is often nothing. Share a short note before the pilot, another before gates change, and a contact for questions. Developers forgive a tool change that was explained and punish one that surprised them. Collect feedback from the pilot group and fix the top three complaints before widening the rollout.
Try it yourself
Click through it at your own pace, or open it full screen. See how an imported backlog looks once it has owners and statuses.
Quick check
How long should I run both setups?
Long enough to cover a full release cycle and a few new advisories, so you can compare results on real events.
Should the first gate block merges?
No. Start in report just mode and switch to blocking after developers trust the results.
Sources
Last reviewed: 19 October 2026.
