Move to a Password Manager With a Recovery Plan

A password manager migration has two jobs: move usable login records into a new vault and leave you able to recover access when something goes wrong. A successful import message proves only that a file was accepted. It does not prove every attachment, recovery code, shared item, or login method survived. Plan the move around a small set of important accounts, then widen the scope after checking the result.

This guide describes a cautious migration process rather than recommending a particular service. Employer-managed accounts may have separate rules, and some credentials cannot be exported between products. Check the current documentation for both your source and destination before creating a file containing sensitive information.

Make an inventory before exporting

Write down the kinds of information you actually use: website logins, secure notes, payment records, attached documents, one-time password generators, shared collections, and passkeys. You do not need to copy the secrets into this inventory. A description such as “email account recovery codes stored separately” is enough. The inventory should explain what requires verification without becoming another password database.

Identify dependencies. Your email may be needed to approve a new vault login, while its password may currently live in the old vault. Your second-factor app may depend on the phone you intend to replace. Keep working access to those dependencies throughout the migration. Avoid changing your password manager, phone, email provider, and authentication method on the same afternoon.

Choose a quiet period when you can stop if an important account fails. Tell anyone who shares a vault with you that a migration is planned, and agree which copy remains authoritative until the cutover is complete.

Establish recovery before filling the new vault

Set up the destination using a strong, unique master password or the account protection method supported by that service. Understand how account recovery works before relying on it. A support team may be unable to restore access to encrypted content if you lose the necessary credentials. Convenience features and recovery arrangements differ between services and account types.

Store recovery information in a place you can reach without first opening the same vault. Follow the provider's guidance for protecting that copy. Test a normal sign-in on a second trusted device if you have one, including the second factor. Confirm you know which account and region you created; similarly named personal and business accounts can cause confusion later.

Do not send recovery codes to yourself through a shared chat simply because it is convenient. Decide who should be able to access them and how that person would find the correct instructions during an emergency.

Understand the export format

Read which fields each supported export format includes. A basic comma-separated file may carry login names and passwords but omit information another format preserves. Bitwarden, for example, documents that standard CSV and JSON exports are unencrypted and distinguishes encrypted export options. That is a product-specific illustration of why the filename alone is insufficient evidence of protection. See its vault backup guidance before using its export options.

Choose the most complete format that the destination explicitly supports. An encrypted backup is useful only if the destination can read it and you retain the required key or password. Do not assume an encrypted export made for one account is a portable migration file for every other service.

Create the export on a trusted device in a location you control. Avoid a folder that automatically shares new files with coworkers. Treat temporary exports as sensitive throughout their lifetime, including any copies placed in downloads, backups, or synchronization history.

Import a small representative sample

If the tools permit it, start with a separate test collection containing a few noncritical records. Include a login with a long note, a record with multiple website addresses, and any unusual item type you use. Compare the source and destination field by field. A title and username can look correct even when the intended website address or custom field is missing.

Find out whether repeating an import creates duplicates or updates existing records. Do not repeatedly import the full file to troubleshoot one missing field. Use the provider's instructions to clean up a test import or choose a fresh destination before trying again. Keep a short migration log recording the file date, item counts, and any unsupported types.

Counts are a useful warning signal, not a complete test. Two services may count folders, shared records, and personal records differently. Investigate differences using the inventory rather than forcing the totals to match blindly.

Verify real access carefully

Check your main email, a routine shopping account, and an account that uses a separate second factor. Visit known addresses directly and confirm the new manager offers the expected record. A failed autofill may indicate an address-matching setting rather than a bad password. Inspect the record before changing a working account password.

Review shared access separately. Imported personal copies may not preserve who is allowed to use a team credential. Confirm ownership and permissions with the people responsible for the shared account. Where a credential type cannot be moved, follow the service's supported process to enroll a new method while retaining a working fallback.

Never test recovery by deliberately locking yourself out of your only working account. A rehearsal should confirm that instructions and materials are available, not create an unnecessary emergency.

Cut over and remove temporary exposure

Once the destination is verified, choose it as the place for new and updated credentials. Keeping two independent vaults active indefinitely creates uncertainty about which password is current. Retain the old account for an appropriate transition period without making parallel edits, then follow its documented closure or retention process.

Remove unencrypted export files and unnecessary copies after confirming a usable protected backup. Deletion behavior depends on the device, storage service, backups, and retention settings; clearing one visible folder does not prove every historical copy disappeared. If an export was accidentally shared, assess which credentials were exposed and change them through their legitimate services.

Finish with a brief record of what moved, what required manual enrollment, where recovery instructions are kept, and when the next recovery check should happen. The best result is not simply a tidier vault. It is a system you can use, maintain, and recover without depending on memory alone.

Illustrative stock photo: Dell / Unsplash. Unsplash License.