Tell developers early, in plain words, what changes on which date, why, and what they need to do. Send three short messages: an advance notice, a cutover reminder and a first week follow-up. Name one channel for questions and say what stays the same, because surprise is what creates resistance.
What developers worry about
Not the tool itself. They worry about broken builds, new noise on code they thought was clean, and lost context on findings they were already working. Address those before anything else.
Message one: the advance notice
Send it a few weeks before any change. Include:
- What is changing and the reason in one sentence. Be honest. "We are reducing the number of tools to maintain" is better than a vague promise.
- The dates for each stage, and which teams go when.
- What you will do for them: migrate suppressions, keep existing findings visible, run both tools for a period.
- What they need to do, if anything. Ideally nothing at first.
- Where to ask questions.
Message two: the cutover reminder
Send it a few days before a team's date. Say exactly what they will see differently in a pull request: where the comment appears, what the new check is called, and what happens when it fails. A screenshot helps more than a paragraph.
Message three: the first week follow-up
After the cutover, report what you found and fixed. If you changed a threshold because of feedback, say so. This is the message that builds trust for the next change.
Make feedback cheap
Offer a single channel and respond fast. Keep a visible list of reported problems with status. Developers forgive a new tool with bugs that get fixed; they do not forgive silence.
Keep a short FAQ
Collect the same five questions you keep answering and pin them. Typical ones: why did the check name change, how do I suppress a finding, who do I contact.
What to avoid
- Announcing a change the day it happens.
- Blaming the old tool or the people who chose it.
- Promising that nothing will break. Say what you tested and what you will watch.
- Burying the dates in a long document.
A short, specific message that admits what you do not know yet is read more often than a polished one. If dates move, say so in the same channel, and say why.
Quick check
Should the announcement come from security or from engineering leadership?
Ideally both. Security explains the reason and the plan, an engineering leader confirms it is a priority and the dates are real.
How much notice is enough?
Enough that a team can fit the change into their planning. Many teams need a couple of weeks, longer if their release calendar is tight.
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.
