Yes. Keep the old build working, build the same artifact with the new tool, and compare the two before switching. Compare file contents and the resolved dependency list, and explain every difference. The Gradle migration guide recommends exactly this, and the idea applies to any package manager or build tool change.
What the guidance says
The Gradle guide for leaving Maven gives general rules that travel well. Keep the old and new builds side by side, because you know the old one works. Develop a mechanism to verify that the two builds produce the same artifacts, which the guide calls vitally important, since even small changes such as the contents of a manifest file in a JAR can cause problems. Focus on critical output such as published or deployed artifacts. Expect inherent differences, such as file order in archives, and verify that they are acceptable.
A parallel run plan
- Branch, then add the new tool next to the old one. Do not remove anything yet.
- Build with both from the same commit in a clean environment.
- Compare, in this order: resolved dependency lists, packaged artifact contents, test results, container image layers if applicable.
- Record differences with an explanation each.
- Run both in CI for a defined period, for example one release cycle.
- Cut over when the explained list is stable, then remove the old tool in a separate change.
What to compare
| Layer | How | What a difference may mean |
|---|---|---|
| Dependency list | Diff name and version pairs | Resolver behavior changed |
| Artifact contents | List files in each archive and diff | A scope or exclusion changed |
| Registry sources | Review repositories and indexes | A new trust path was added |
| Checksums | Hash the artifacts | Expect differences from timestamps, then rule them out |
Reproducibility noise, such as timestamps in archives, makes byte for byte comparison hard. Compare contents first, and treat hashing as a bonus.
Why this is a supply chain control
A migration is a moment when many defaults change at once: resolution rules, script permissions, registry settings and cache locations. A parallel run turns those unknowns into a short list. It is also good audit evidence, because it shows that a change to the build was verified. For the audit angle see keep audit evidence continuous during a tool migration. For scanner changes the same logic appears in compare SBOM output before and after a scanner switch.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how ongoing monitoring flags new findings over time, which is useful for the weeks after a cutover.
Safeguard's dependency scanning, SBOM generation and continuous monitoring help you compare and then watch both sides. A free scan is at gold.safeguard.sh/scan.
Quick check
How long should both builds run?
Long enough to ship at least one real release from the new build and compare. For many teams that means one release cycle.
Do artifacts need to be byte identical?
Not usually. Expect harmless differences such as file order, but explain each one.
Sources
Last reviewed: 19 October 2026.
