A realistic plan runs about 90 days in four stages: 30 days to inventory and map your history, 20 to trial the import, 30 to run both tools in parallel, and 10 to cut over and review. Smaller teams can compress it. The order matters more than the exact numbers.
Why 90 days
The tool switch itself takes hours. The time goes into everything around it: finding where decisions live, agreeing on reasons, testing an import, and waiting long enough to see a full release cycle on both scanners. Plans that skip the parallel run tend to discover differences in production.
Adjust the length to your estate. A team with ten repositories can do this in a month. An organization with hundreds of projects and an audit calendar may need more.
The plan
| Days | Stage | Key outputs |
|---|---|---|
| 1 to 10 | Inventory | List of decision sources, field list, counts, owners |
| 11 to 30 | Mapping | Reason translation table, project mapping, import rule for suppressions |
| 31 to 40 | Vendor tests | Answers on import, trial import of 50 decisions, spot check |
| 41 to 50 | Full import to a staging scope | Import log, orphan list, count reconciliation |
| 51 to 80 | Parallel run | Both tools scanning, gates in report only mode, diff reviews |
| 81 to 90 | Cutover and review | Gates switched, relink done, old tool read only, review at 30 days |
Stage one: inventory
Find every place a decision lives: the scanner, tickets, spreadsheets, pull request comments and chat. Count them. Decide which are in scope. Request an export from the old vendor early and test it, so you learn about gaps while you still have time.
Stage two: mapping
Agree on a vocabulary for reasons, with a translation table. Map projects, teams and owners. Write the rule for which old suppressions to import: reason, owner, age and existence. Decide how first detected dates and deciders will be preserved.
Stage three: trial the import
Ask the new vendor the import questions in writing, then run a trial with a small sample of awkward records. Verify with a stratified sample of 20. Fix the script before scaling.
Stage four: parallel run
Scan with both tools for at least one release cycle. Keep the new gates in report only mode and compare what each would have blocked. Review the findings only one tool reports. Resolve the orphan list. This is the stage that justifies the 90 days, because it exposes coverage gaps with real code.
Stage five: cutover and review
Freeze edits in the old tool, run the final export, import, verify, switch gates, then relink tickets before turning on ticket creation. Keep the old tool read only for a defined period. At 30 days, review the metrics against the baseline: open findings, suppression rate, median age and reopen rate.
Exit criteria
Write these at the start, not the end.
- Orphans due to coverage gaps are resolved or accepted by a named owner
- Counts reconcile within a stated tolerance
- The spot check passes
- Gates in report only mode agree with the old tool on an agreed share of pull requests
- The archive of the old export is stored with a hash
A note on Safeguard
Safeguard offers SBOM and dependency scanning, policies and gates, and compliance and evidence automation. If you want an independent view during the parallel run, you can try a free scan at gold.safeguard.sh/scan.
Try it yourself
Open the demo and see how continuous monitoring surfaces changes over time. During the parallel run, this is the behavior you are comparing between tools.
Click through it at your own pace, or open it full screen.
Quick check
Can we do this in 30 days?
For a small estate, yes, by shortening each stage. Keep the parallel run and the exit criteria.
Should the audit calendar affect the plan?
Yes. Avoid cutover close to an audit window, or keep extra evidence of the old tool's records ready.
Last reviewed: 19 October 2026.
