Run pnpm import in the project root. It reads package-lock.json, npm-shrinkwrap.json or yarn.lock and writes a pnpm-lock.yaml from it, so the versions you already ship are the starting point. If you use workspaces, declare them in pnpm-workspace.yaml first. Then verify the result before committing.
What pnpm import actually does
The pnpm documentation describes the command in one sentence: it generates a pnpm-lock.yaml from another package manager's lockfile, and the supported sources are package-lock.json, npm-shrinkwrap.json and yarn.lock. That matters for security because the alternative, deleting the old lockfile and running a fresh install, asks the resolver to pick new versions for everything. A fresh resolve is an upgrade of your whole tree, done silently, on the day you changed tools.
Importing keeps the pins you had. It is the closest thing to a like for like move.
Steps
- Work on a branch and make sure the current build is green on the old package manager.
- If the repository uses workspaces, create pnpm-workspace.yaml and list the packages. The pnpm docs say workspaces must be declared there beforehand, or the import will not cover them.
- Run the import.
- Run an install from the new lockfile.
- Compare the old and new dependency trees (the next section).
- Commit pnpm-lock.yaml and remove the old lockfile in the same pull request.
pnpm import
pnpm install
Check that nothing moved
Do not assume the import was lossless. Export a flat list of name and version pairs from the old lockfile and from the new one, sort both, and diff them. Any line that differs is a decision someone should look at. Typical causes are peer dependencies being resolved differently, optional dependencies for other platforms, or a package that the old lockfile had twice at different versions.
If you need a refresher on why the file matters, see what a lockfile is and why to commit it and how to verify resolved versions after switching package managers.
Things the import will not fix for you
An import converts the lockfile. It does not convert your scripts, your CI install step, or your registry credentials. The package.json scripts may call npm explicitly, and a Dockerfile may still run an npm install against a lockfile that no longer exists. Search the repository for the old command name before you merge. Also confirm the install runs with the frozen lockfile mode in CI: the pnpm docs state that in a CI environment the install fails if a lockfile is present but needs an update, which is exactly the behavior you want after a migration.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a dependency inventory lists every direct and transitive package with its version, which is the list you want to diff before and after the switch.
Safeguard's SBOM and dependency scanning produces that inventory from a repository, and you can try a free scan at gold.safeguard.sh/scan on the branch before and after the change.
Quick check
Does pnpm import also convert yarn.lock?
Yes. The pnpm docs list yarn.lock, package-lock.json and npm-shrinkwrap.json as supported source files.
Is it safer to delete the old lockfile and start fresh?
Not for a tool switch. A fresh resolve can select newer versions for the whole tree. Import first, confirm the versions match, and upgrade later in a separate pull request.
Sources
Last reviewed: 19 October 2026.
