When two companies run separate package registries, decide one source of truth for each ecosystem, then align who can publish, what can be pulled from the public internet, and how long artifacts are kept. Migrate consumers in small groups, and keep the old registry read only until nothing depends on it.
Why registries are a policy question, not just plumbing
A registry is where your dependency rules become physical. If one team can pull any package straight from a public index and the other must go through a reviewed proxy, you have two different security postures regardless of what the policy document says.
The checklist
1. Inventory both registries. List each registry, each ecosystem it serves, how many repositories depend on it, and who administers it. Include hidden ones: a container registry someone created for a side project counts.
2. Choose the target per ecosystem. You do not need one product for everything. You need one decided home per ecosystem, so there is never a question of where a package should come from.
3. Align publishing rights. Compare who may publish, whether publishing needs review, and whether tokens are scoped and expire. Take the tighter setup as the starting point, and check that the merged team has an owner for token hygiene.
4. Align the pull path. Decide whether builds may reach public indexes directly. A proxy with an allow list or a cooling off period for brand new versions gives you one place to apply rules.
5. Handle internal package names. If both companies have internal packages, check for name collisions. Two different internal packages with the same name can confuse a build that now sees both registries. Reserve names in the public index where it makes sense, and configure scopes so internal names never resolve externally.
6. Set retention. Decide how long old versions are kept. Releases you shipped to customers should stay available for rebuilds and investigations. Review what to archive for each software release.
7. Plan credentials. Every pipeline that publishes or pulls has a credential. List them, rotate them during the move, and revoke the old ones when the old registry goes read only.
Migration order
- Mirror packages into the target registry while the old one stays live.
- Move a pilot repository and compare build output.
- Move repositories in groups, lowest risk first.
- Set the old registry to read only.
- Remove it after a quiet period with no pulls.
Check for dependency confusion exposure
During any consolidation, look for builds that fall back to a public index when an internal package is missing. That fallback is the weakness behind dependency confusion. Test it explicitly by requesting an internal package name that does not exist and confirming the build fails rather than going public.
Try it yourself
Click through it at your own pace, or open it full screen. Notice that each dependency lists its source, which helps you see which registry each build really uses.
Safeguard's dependency scanning and asset discovery can help you find which repositories and services pull from which sources before you migrate.
Quick check
Do we need a single registry product?
No. You need one decided home per ecosystem and one set of rules, even if more than one product is involved.
When can we delete the old registry?
After it has been read only for a quiet period with no pulls, and after you have confirmed that release artifacts you must keep are copied.
Last reviewed: 19 October 2026.
