When two internal teams combine or repositories are merged, check dependency rules before you move code: who owns the combined repository, which versions and scanners apply, how new dependencies are approved, and where exceptions live. Settle these first, and the merge itself becomes a mechanical step.
This is smaller than a company merger, but the same questions apply
Reorganizations happen without any acquisition. Two teams become one. A set of services is pulled into a single repository. A platform team takes over a library. Each version of these has the same hidden problem: two sets of habits meet in one place.
The checklist
Ownership
- Name an owner for the combined repository and for its dependency decisions.
- Update the code owners file and the security contact.
- Move open findings and exceptions to the new owner.
Inventory
- Generate a dependency list for each repository before the merge, and another after. Compare them.
- Check for the same library at different versions, and decide on one. See duplicate dependencies across merged codebases.
- Look at lockfiles. Two lockfiles in one directory structure need a plan for which one is the source of truth.
Rules
- Compare each team's dependency rules: license list, severity thresholds, approval steps.
- Pick the merged rules using the method in how to merge two dependency policies after a merger.
- Record exceptions that carry over, with new expiry dates.
Tooling
- Decide which scanner and which update bot configuration applies, then remove the other.
- Check that the pipeline still scans every changed path. A common slip is a monorepo scanning only the root.
- Verify that path based rules in the gate match the new folder layout.
Access
- Review who can merge, who can approve, and who can publish from the repository.
- Check branch protection and required checks after the move.
History
- Keep the old repository archived and read only, not deleted, for audit and for investigations.
- Preserve tags and release records for versions you shipped.
Common problems after a merge
| Problem | Why it happens | Fix |
|---|---|---|
| Scans cover only part of the repository | Config paths were not updated | Test with a known finding in each folder |
| Duplicate bot pull requests | Both old configs still active | Remove one, keep a single config |
| Gate passes everything | Policy file path changed | Confirm the gate reads the current policy |
| Exceptions stop applying | They referenced old repository names | Re-key them to the new location |
Do a smoke test
After the merge, introduce a harmless test dependency that your policy should block, such as one on the deny list, on a branch. Confirm that the gate fails the pull request. Then remove the branch. It is the quickest proof that the rules still apply to the new layout.
Try it yourself
Click through it at your own pace, or open it full screen. Look at the check that runs on the pull request, and imagine which file it reads its rules from.
Safeguard's dependency scanning and policies can run across the merged repository, and its free scan at https://gold.safeguard.sh/scan can compare the before and after state of a codebase.
Quick check
Should we merge repositories before aligning dependency rules?
Align the rules first where you can. It is easier to agree on rules than to untangle a combined repository that two sets of rules have already shaped.
Why archive the old repository?
Past releases, findings, and approvals refer to it, and audits and investigations may need it later.
Last reviewed: 19 October 2026.
