Roll back a scanner migration when a pre-agreed trigger is hit: a confirmed coverage gap, builds broken beyond a set threshold, scan times that miss deploy windows, or known issues the new tool misses. Write the triggers down before cutover and keep the old tool available until the new one has passed.
Why decide in advance
Mid-migration, sunk effort and schedule pressure push people to continue. Triggers set while calm remove the argument. They also reassure developers that a bad experience has an exit.
Triggers worth considering
| Trigger | Example threshold style |
|---|---|
| Coverage gap | A language, registry or repository type not scanned that the old tool covered |
| Missed known issues | Known vulnerable sample not detected |
| Build failures | More failed pipelines than a threshold you set, caused by the scanner |
| Scan duration | Longer than your deploy window allows |
| Data or access problem | Authentication, permissions or data handling issue found |
| Support | Critical blocking issue unanswered beyond an agreed period |
Set the numbers from your own pipelines. Avoid copying numbers from another organization.
What you need to make rollback possible
- The old tool's contract and access remain active through the overlap period.
- The old pipeline steps are disabled behind a flag, not deleted. See rollback plan checklist before shipping.
- Exceptions and configuration are exported, so nothing was lost.
- One person has authority to call the rollback.
Roll back one wave, not everything
With a staged plan, roll back the affected team or wave and keep the rest. See big bang or team by team.
After a rollback
Record the cause, fix it, and set a new date. A rollback that produces a clear finding is a successful use of the plan.
Point of no return
Name the date when the old tool is retired and its contract ends. Before it, confirm every trigger has been clear for a full release cycle and the new tool passed your tests from the coverage matrix.
A sample trigger sheet
Write one line per trigger: the condition, who measures it, how often, and who decides. For example, build failures caused by the scanner are counted by the engineering lead each day during a wave, and the project owner decides on pause. Put the sheet where the wave teams can see it. Visible triggers make developers more willing to go first.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through the gate demo and see what a blocked merge looks like. Your rollback flag should be able to turn that blocking behavior off per team.
Quick check
Is a rollback a sign of failure?
No. It is the plan working. The failure would be continuing with a known gap.
How long should we keep the old tool?
Through at least one release cycle after the last wave, and past your audit or reporting date if evidence depends on it.
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.
