Migration effort is driven by how many repositories and pipelines you have, how varied they are, how much custom configuration the old tool holds, how many integrations depend on it and how many teams must approve. Score each driver low, medium or high before you promise a date.
Why not give a number
Public rules of thumb for hours or weeks mislead, because the spread between organizations is huge. A team with one pipeline template and no custom rules moves quickly. A team with ten templates, years of suppressions and tickets wired to the old tool does not. Estimate from your own drivers instead.
The drivers
| Driver | Low effort | High effort |
|---|---|---|
| Repository count | Dozens | Thousands |
| Pipeline variety | One shared template | Many bespoke builds |
| Custom rules and policies | Defaults | Years of tuning |
| Suppressions and exceptions | Few, documented | Many, undocumented |
| Integrations | Code host only | Tickets, chat, dashboards, SIEM, custom scripts |
| Reports consumed | Internal only | Customer or auditor facing |
| Teams and approvals | One group | Many groups, change boards |
| Languages and ecosystems | Mainstream | Niche or private registries |
How to use it
- Score each driver for your estate.
- Mark any driver that is unknown as high until you check. Unknowns are where plans slip.
- Spend a day sampling three or four repositories of different kinds. Note what actually breaks.
- Turn the highest drivers into work items: a rule inventory, a suppression export, an integration list.
Do the cheap discovery first
Our posts on inventorying your tools and the scanner migration checklist for integrations, tokens and reports find most of the hidden work.
Include the human work
Technical steps are usually the smaller share. Communication, training, answering questions and waiting for approvals take time too. See telling developers a scanner is changing.
Use ranges and checkpoints
Give a range, name the drivers behind it, and re-estimate after the pilot wave. Stakeholders accept uncertainty when they can see its source.
An example of scoring
Suppose you have a few hundred repositories, two pipeline templates, default rules, a large pile of undocumented suppressions and tickets created automatically by the old tool. Repository count is medium, pipeline variety low, rules low, suppressions high, integrations medium. The suppressions and the ticket link are your work items. Plan time for them first, and the schedule will be closer to real than a flat per repository estimate.
Quick check
Should I ask the vendor for a migration estimate?
Yes, but treat it as one input. The vendor does not know your custom pipelines and suppressions.
Is a pilot enough to estimate the rest?
It is a good basis if the pilot teams differ in stack. A pilot on the easiest repositories understates the work.
Safeguard covers SBOM and dependency scanning, reachability analysis, policies and gates, and compliance evidence automation. You can try a free scan at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
