No. Do the migration with versions preserved, merge it, then upgrade dependencies in a separate pull request. When both land together, a regression has two suspects, the reviewer cannot tell a tool effect from a version effect, and you cannot roll back one without the other.
Two changes with different risks
A package manager migration changes how packages are resolved, fetched and installed. A dependency upgrade changes which code runs. Each deserves its own review question. For the migration: did anything move that should not have? For the upgrade: is the new code safe and compatible?
Mixed together, a lockfile diff of thousands of lines becomes unreviewable, and a real downgrade or a hostile new version hides in the noise.
How to preserve versions in the migration
Most tools give a way to carry the old pins across. The pnpm import command builds pnpm-lock.yaml from package-lock.json, npm-shrinkwrap.json or yarn.lock. The uv migration guide shows adding requirements with the old pinned file as constraints so existing versions are retained. Yarn Modern migrates the lockfile on the first install. For Maven to Gradle, the resolution rules differ, so compare the trees and pin differences, as in why versions change from Maven to Gradle.
The two pull requests
| Pull request | Goal | Review focus |
|---|---|---|
| 1. Migration | Same versions, new tooling | Diff of resolved lists, CI, registry settings, scripts |
| 2. Upgrade | Newer versions on purpose | Release notes, advisories, tests, maintainers |
Between them, run the new setup for a short period. If something odd appears in production, you know the tool change is the only change.
Steps
- Branch from the main branch with a green build.
- Migrate with versions preserved.
- Verify with a diff (see verify resolved versions after switching package managers).
- Merge and ship.
- Start upgrades. The uv documentation notes that a lockfile is not considered outdated when new releases appear, so nothing upgrades until you ask. Use targeted upgrades for security fixes first.
- For the upgrade itself, see what to check in a lockfile diff during code review.
When you must combine them
Sometimes the old tool cannot resolve a safe version, and the migration is the fix. Then say so in the pull request, list the intended upgrades by name, and keep every other version fixed. A short, explicit allow list of changes keeps the review honest.
Urgent security fixes during a migration
If an advisory lands mid migration, patch on the main branch using the old tooling and merge it into the migration branch. Do not fold the fix into the migration. See lockfile only fix versus manifest change review.
Try it yourself
Click through it at your own pace, or open it full screen. See how a fix for a specific vulnerable version is proposed as its own change, which is the shape the second pull request should take.
Safeguard's autonomous remediation can open fix pull requests; it is off by default and every category is on Manual, so changes need your approval. A free scan is at gold.safeguard.sh/scan.
Quick check
Is one big pull request faster?
It is faster to open and slower to review and debug. Two small ones usually finish sooner.
What if a security fix is urgent mid migration?
Ship it separately on the main branch and merge it into the migration branch afterwards.
Sources
- pnpm import
- uv, migrating from pip to a uv project
- uv, locking and syncing
- Yarn, step by step migration
Last reviewed: 19 October 2026.
