To align duplicate dependencies after a merger, inventory both codebases, list libraries used in both at different versions, choose one target version per library based on security status and compatibility, and upgrade in small steps starting with the lowest risk services. Do not force one global bump on everything at once.
Find the overlaps first
You cannot align what you cannot see. Generate a dependency inventory for every repository on both sides, including transitive packages, since those are where hidden duplicates live. Then group by package name and look at how many versions exist across the combined estate.
Sort the result into three buckets:
- Same version everywhere. Nothing to do.
- Different versions, same major. Usually a simple bump.
- Different majors. Real work, possible breaking changes.
Choose a target version
For each overlapping library, weigh four things.
- Security status. Does either version have known vulnerabilities, and is the newer one fixed?
- Support status. Is the version still receiving fixes upstream?
- Compatibility. Does the target work with the frameworks you run?
- Effort. How many call sites use the changed behavior?
Often the answer is the newest version that both sides can run. Sometimes it is a middle version, with a plan to move further later.
| Situation | Typical choice |
|---|---|
| Both versions supported, no known issues | Pick the newer, upgrade the older at next touch |
| One version has known vulnerabilities | Move to the fixed version first |
| One version is no longer supported | Treat as an upgrade project with a date |
| Major versions differ, wide usage | Plan a staged migration, consider an adapter |
Upgrade in an order that limits breakage
Start with libraries that have good test coverage around them. Use update pull requests that change one thing at a time, so a failure points to one cause. Keep the previous version available for a quick revert. More on that in how to roll back a bad dependency upgrade merge.
Beware of shared deployment
If two merged services now run in one process or one container image, duplicate libraries can collide. Two versions of the same logging library on one classpath, for example, can behave unpredictably. Check how your build resolves conflicts, and test the combined artifact rather than each side alone.
Decide what happens when the policy and the code disagree
Your merged policy may forbid a version that is still in use. Do not leave this ambiguous. Either list the repositories as known gaps with dates, or record time bound exceptions. See transitive dependencies policy, who approves what you inherit.
Keep it from drifting back
Once aligned, put a rule in place that new dependencies must match the agreed versions or justify the difference. A shared update bot configuration helps; see how to share one policy set across many repositories.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how versions of each package appear in the inventory, which is where duplicates show up.
Safeguard's SBOM and dependency scanning can produce that inventory across repositories, and its free scan at https://gold.safeguard.sh/scan is a quick way to look at one codebase first.
Quick check
Is one version of every library always the goal?
No. It is a useful direction, but a few deliberate differences with a recorded reason are acceptable.
Do we align before or after enforcing the merged policy?
Run the dry run first, so the alignment list reflects what the policy would actually flag.
Last reviewed: 19 October 2026.
