For anything beyond a handful of repositories, cut over in waves: a pilot team first, then a few teams, then the rest. A single switch for everyone is reasonable only when the estate is small and the pipeline change is trivial. Waves let you find problems while few people are affected.
The two approaches
| Big bang | Waves | |
|---|---|---|
| Speed | Fast on paper | Slower, steadier |
| Blast radius | Everyone at once | One group at a time |
| Learning | Late, under pressure | Early, then reused |
| Support load | Spike | Spread out |
| Fits | Small estates, simple CI | Many teams, varied stacks |
When big bang is acceptable
You have a few repositories, one pipeline template, and the new scanner has already run in parallel on all of them without surprises. The cost of failure is low and rollback is one config change.
How to design waves
- Pilot wave. One or two willing teams with different stacks. Run both scanners and compare.
- Early wave. A handful of teams, chosen for variety, not just friendliness.
- Main wave. Teams grouped by shared pipeline templates so one fix helps many.
- Long tail. Odd repositories with custom builds, handled individually.
Pick wave members by risk too. Put the most business critical systems after you have confidence, not first.
Entry and exit criteria for each wave
Write them down before starting. Entry: the previous wave's open problems are closed or accepted. Exit: the team's pipelines pass, suppressions are migrated and nobody is blocked. See running both tools in parallel before cutting over for the comparison step.
Use pause rules
Agree in advance what stops a wave: a rise in failed builds, scan times that break a deploy window, or a coverage gap found in testing. Pausing is a normal outcome of a staged plan, not a failure.
What to do after each wave
Hold a short review with the pilot or wave teams. Ask what broke, what confused them and what they would change. Fix shared causes in the pipeline template or the policy, not team by team, so the next wave starts cleaner. Update the one page guide and the FAQ. Keep the old scanner running for the teams still waiting, and keep an eye on ongoing scan health once a team has moved.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through the continuous monitoring demo and look at how scan results are tracked over time. After a cutover, that ongoing view is how you confirm a migrated team stays covered.
Quick check
How long should each wave run?
Long enough for a team to go through at least one full release cycle on the new scanner. That is when pipeline and workflow problems tend to surface.
Can waves overlap?
Yes, once the pilot is stable, but avoid starting a new wave while the previous one still has open blockers.
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.
