Editorial illustration; the devices, records and labels are representative examples rather than a live password manager.
Moving to a password manager sounds like a single task: install an app, import passwords and start using it. In practice, the difficult part is the transition. Passwords may be spread across a browser, phone, notes file, old computer and family member’s memory. Recovery details may be incomplete. An imported export may contain duplicates or passwords you should no longer keep.
The useful question is not “Which password manager is best?” It is “How can I move my important accounts into one controlled system and prove that I can still sign in if my main device disappears?” This guide focuses on that migration problem. It does not recommend one commercial product, and it does not assume that every account supports the same recovery options.
Summary
- Build an account inventory before exporting anything; start with email, banking, work and identity-recovery accounts.
- Import into one chosen vault, then review duplicates, obsolete records, shared credentials and recovery information.
- Replace reused or weak passwords in priority order, but test the new sign-in before deleting the old record.
- Add a second recovery path and verify it in a private or separate session.
- Delete exported files and retire browser storage only after the vault and recovery process work.
What problem are you actually solving?
A password manager reduces the pressure to memorise many unique passwords. CISA recommends using a password manager as part of stronger account security, while also recommending multifactor authentication where it is available. A manager is therefore a storage and generation tool, not a replacement for account recovery or a second authentication factor.
The migration has four separate outcomes:
- You know which accounts matter and where their current credentials live.
- The vault contains accurate records with enough context to use them.
- Important accounts accept the new credentials and a tested recovery method.
- Old copies no longer remain in places you forgot about.
If you only achieve the second outcome, you may have created a tidy vault but not a reliable access plan.
Step 1: Make an inventory before you import
Create a temporary list of account names, not passwords. Group the list by consequence if access is lost:
- Recovery accounts: your main email, phone provider and identity provider. These can reset other accounts.
- High-impact accounts: banking, tax, government, work administration and cloud storage.
- Communication and social accounts: messaging, professional networks and personal profiles.
- Low-impact accounts: newsletters, shops and old services that can be closed.
For each important account, record the sign-in address, the username or email used, whether multifactor authentication is enabled, and where recovery codes are stored. Do not paste a password into this inventory. The purpose is to identify gaps without creating a second secret store.
This is also a good time to close accounts you no longer need. An account that cannot be identified, recovered or deleted should be treated as an unresolved item rather than silently imported forever.
Step 2: Choose the vault and establish its recovery path
Before importing, decide where the vault will live and how you will recover it. Read the provider’s official documentation for account recovery, device approval, export and emergency access. The exact controls differ between services, so do not assume that a feature exists because another product has it.
Use a long, unique vault passphrase. If the product supports an authenticator app or security key as a second factor, configure it before loading the rest of your accounts. Save recovery codes in a place that is available when your primary phone is unavailable but is not exposed in an ordinary notes app or shared screenshot.
The test is simple: from a separate browser profile or another trusted device, confirm that you understand the sign-in and recovery sequence. You do not have to simulate a disaster by deleting your only device. You do need to know which factor is requested and where the backup code is located.
Step 3: Import in a controlled batch
Most browsers and managers can export credentials to a file. Treat that file as a temporary high-risk copy. Anyone who can read it may be able to read the passwords inside it. Export locally, import through the selected manager’s documented process, and remove the export after verification. Avoid sending it by email, placing it in a shared drive, or leaving it in a downloads folder that syncs to several devices.
Do not import every record in one blind operation if the source contains years of clutter. Start with a small batch of accounts that you recognise. Check how the importer maps usernames, URLs, notes, passkeys and one-time-code fields. Some records may be duplicated because the same site uses several sign-in domains; others may point to a login page that has moved.
After the first batch, open several records and confirm that the vault shows the right account, not merely a plausible title. A useful record should tell you which email is used, which site is authoritative, and whether a note contains a recovery instruction rather than another unprotected secret.
Step 4: Replace passwords by priority, not by alphabetical order
The highest-value change is usually removing reuse from accounts that can reset everything else. Change your primary email first, then the accounts that control financial, work or identity data. Generate a unique password in the manager and save it only after the site accepts it.
For each account, use this small loop:
- Sign in using the old credential.
- Open the account’s security settings directly from the official site or app.
- Generate a new unique password and save it in the vault.
- Sign out, then sign in again using the vault entry.
- Check that recovery email, phone and multifactor settings are still correct.
This loop prevents a common failure: changing a password, assuming the manager saved it, and discovering later that the record contains the previous value or the wrong username. If an account has active sessions on old devices, review the provider’s sign-out or session-management controls and use them when appropriate.
For a broader account review, the passkey access plan explains why a second sign-in and recovery test should happen before weaker methods are removed. The two workflows can coexist: a manager handles passwords, while passkeys or security keys provide another sign-in option where supported.
Step 5: Test the uncomfortable cases
A migration is not finished when the app opens on your current phone. Test the cases that would actually interrupt your work:
- Can you open the vault on a second trusted device?
- Can you sign in if your main browser profile is damaged?
- Can you locate recovery codes without searching the vault itself?
- Can a family or work delegate follow the documented emergency process, if that responsibility exists?
- Do browser autofill and mobile autofill select the intended account rather than an old duplicate?
Use a separate browser profile for the test so that a saved session does not hide a missing password. Avoid testing recovery by making irreversible changes. You are checking the path, not trying to lock yourself out.
Step 6: Clean up old copies last
Only after the important accounts pass the sign-in test should you remove old browser entries, plain-text notes and temporary export files. Search the locations where the old data actually lived: browser password settings, downloads, desktop folders, cloud-sync folders, backup snapshots and shared documents. A synced export can survive on another device even after you delete the local file.
Do not delete an old record merely because the new vault contains a record with the same name. Compare the username, site and recovery details first. If an account is shared, agree on ownership and access before removing anyone’s copy. If a work account is controlled by an organisation, follow its policy instead of moving credentials to a personal vault.
Mistakes to avoid
The most damaging shortcuts are predictable:
- Exporting the whole browser and leaving the CSV file in a synced folder.
- Changing many passwords without testing any new sign-in.
- Storing the vault’s only recovery code inside the vault.
- Treating a password manager as a substitute for multifactor authentication.
- Keeping duplicates because the same website has several old login URLs.
- Migrating work or shared credentials without checking ownership and policy.
The answer to all six is sequencing. Inventory first, import in a small batch, verify, strengthen high-impact accounts, then clean up.
Why this matters
The benefit of a password manager is not just convenience. It is the ability to make unique credentials practical and to see which accounts still depend on weak or repeated secrets. The migration itself is where many people create new risk because temporary exports, forgotten devices and untested recovery paths are easy to overlook.
If you take one action today, inventory your recovery accounts and test the vault’s second-device sign-in before changing anything else. That gives you a safe foundation for the slower work.
My Take
I would measure a migration by recoverability, not by how quickly the old browser list disappears. A small, verified vault is more useful than a complete import nobody has checked. Keep the transition boring: one account, one new credential, one successful sign-in, one clear recovery path.
Conclusion
A password-manager migration is a controlled change to your account access system. List the accounts, establish recovery, import carefully, replace reused passwords in priority order, test from a separate session and remove old copies last. The result should be more than a new app on your phone: it should be a sign-in process you can explain and use when your usual device is unavailable.