How to Migrate to a New Password Manager Safely

Changing password managers is not a normal file transfer. A password export can contain the keys to your email, financial accounts, cloud storage, and recovery systems in readable text. The safest migration keeps that exposure brief, verifies the new vault before retiring the old one, and treats passkeys and emergency access as separate work.

This field manual provides a vendor-neutral procedure. Menu names and supported formats differ, so check the documentation shown by both managers before you export anything.

Before you start#

Set aside enough time to finish the export, import, initial verification, and plaintext cleanup in one session. Use a trusted device that you control. Install operating-system and browser updates first, and stop if you suspect that the device contains malware.

You will need:

• Access to the old password manager and its primary authentication method
• A working account in the destination manager
• Access to the email account used for security notices and recovery
• Any required hardware security keys or authenticator devices
• Enough local storage for the export and any attachments
• A private location where you can complete the migration without interruption
• A written list of your most important accounts

Your priority list should include your primary email, password-manager account, device-platform account, mobile carrier, financial accounts, domain registrar, cloud storage, identity provider, and any account that can reset other accounts.

1. Confirm that the destination is suitable#

Do not export the old vault until you know what the new manager can accept. Check the destination manager's current import documentation and compare it with the export formats available from the source.

Review these data types separately:

• Login names and passwords
• Website addresses
• Secure notes
• Payment cards and identities
• Custom fields
• Folder, collection, or tag assignments
• File attachments
• One-time-password seeds
• Passkeys
• Shared records
• Item history
• Deleted or archived items

An import feature may support login records without supporting every field attached to them. Unsupported data might be omitted, flattened into notes, or require manual transfer.

If you are still selecting a destination, confirm its import coverage, export options, recovery design, sharing model, and support for the devices and browsers you use. The following are examples of established hosted password managers, not universal recommendations.

2. Secure the new password-manager account#

Protect the destination before it receives your data.

Create a unique account password that is not stored in the old vault as your only copy. Record it using a temporary offline method that you can protect during setup. Enable the strongest practical multi-factor authentication offered for your account, and save any recovery code as instructed by the provider.

Review:

• The account email address
• Multi-factor authentication
• Recovery codes or recovery keys
• Trusted devices and active sessions
• Browser extensions and mobile applications
• Biometric unlock settings
• Automatic lock and clipboard-clearing options
• Account-recovery or emergency-access settings

Do not rely on memory for a newly created account password until you have confirmed that you can unlock the new vault on more than one intended device.

3. Inventory the old vault#

Create a high-level inventory without copying secrets into a separate document. Record counts rather than credential contents.

Count or note:

• Active login records
• Secure notes
• Cards and identity records
• Attachments
• Passkeys
• Records with one-time-password codes
• Shared folders or collections
• Archived and deleted records
• Items owned by an organization, family, or employer

The old manager's total item count might include records that the destination counts differently. Use category counts where possible and expect to investigate reasonable differences.

Also review the old vault for records that should not move. Remove only items that you are certain are obsolete. When in doubt, keep the record for the first import and resolve it later.

4. Prepare a protected working location#

Create a new local folder solely for the migration. Keep it outside folders synchronized by cloud-storage software. Restrict access to your user account if the operating system permits it.

Full-disk encryption helps protect files when the device is powered off, but it does not make an open plaintext export safe from malware, other active processes, or an unlocked user session.

Before exporting:

1. Pause cloud backup or synchronization software if it could capture the working folder.
2. Close applications that do not need to be open.
3. Clear the browser's download setting if it automatically sends files to a synchronized folder.
4. Confirm the exact destination path for the export.
5. Avoid clipboard managers, screen-sharing tools, and session-recording software during the migration.

5. Export from the old manager#

Use the source manager's documented export function. Select the format explicitly supported by the destination. If multiple formats are available, choose the one that preserves the required fields while minimizing plaintext handling.

Export attachments separately only when necessary. Keep them in the protected working location and do not open files unless you must verify them.

After the export finishes:

• Confirm that the file exists in the intended folder.
• Confirm that no second copy was saved in Downloads.
• Do not email, upload, print, or paste the export.
• Do not edit the full export in a spreadsheet application unless field repair is necessary.
• If you must edit it, work locally and account for temporary, autosave, and recovery files created by the editor.

Do not disable or delete the old account at this stage.

6. Import into the destination#

Use the destination manager's documented import function. Select the correct source manager and file format when prompted; a generic importer might map fields less accurately.

Import the file once. Repeating an import can create a second copy of every record.

When the import completes, record the reported number of imported and rejected items. Save error messages without copying secret values into notes or screenshots.

If the import fails:

1. Leave the old vault unchanged.
2. Determine whether the failure affects the full file or specific records.
3. Check the selected source format and file encoding.
4. Use the importer's error report, if available.
5. Repair only the affected rows or fields.
6. Remove rejected secret data from diagnostic files when the problem is resolved.

7. Reconcile counts and missing data#

Compare the destination with the inventory from the old vault. A matching total is useful, but it is not proof of a complete migration.

Check each record category. Investigate:

• Lower or higher item counts
• Empty usernames or passwords
• Website addresses moved into notes
• Missing custom fields
• Broken non-ASCII characters
• Multiline notes with altered formatting
• Missing attachments
• Lost folder or tag assignments
• Records imported as generic notes
• Rejected or truncated entries

Keep a short migration log containing categories and counts, not passwords, recovery codes, or one-time-password seeds.

8. Verify important logins#

Test a representative sample before changing browser integrations or removing the old manager. Always include the high-priority accounts identified earlier.

For each selected account:

1. Open the saved website address from the new manager.
2. Confirm that it points to the expected domain.
3. Fill or copy the username and password.
4. Complete multi-factor authentication.
5. Confirm that the account opens normally.
6. Sign out and verify that the new manager can fill the login again.
7. Check any related recovery email address or telephone number.

Also test examples with unusual data: multiple logins on one domain, custom fields, long notes, identity records, attachments, and credentials for mobile applications.

Do not change every password during the migration. Simultaneous password rotation makes it harder to distinguish an import error from a password-change error. Change a password immediately only when you believe it is exposed, reused, or otherwise unsafe.

9. Audit passkeys separately#

Treat passkeys as a separate migration project. Do not infer that a successful password import included them.

Create a passkey inventory in the old manager without recording private key material. For each account, determine:

• Whether a passkey exists
• Whether another sign-in method still works
• Whether the destination manager shows the passkey
• Whether the service permits more than one passkey
• Whether the old passkey can be removed after a replacement works

Where transfer is not supported, use the account's security settings to create a new passkey in the destination. Test it in a fresh sign-in session before removing the old passkey.

Keep at least one verified recovery route while making the change. That route might be another passkey, a hardware security key, a recovery code, or a password plus multi-factor authentication, depending on the account.

10. Check one-time-password codes#

Some vault records contain the secret used to generate time-based one-time passwords. A normal password export might omit this field or expose it in plaintext.

For each important account that uses codes stored in the old manager:

1. Check whether the destination generates a code.
2. Compare the result during the same time window.
3. Test a real login with the destination's code.
4. Keep the old generator active until the test succeeds.
5. If transfer failed, reset multi-factor authentication through the account's security settings.
6. Store new recovery codes securely and invalidate superseded codes when the service permits it.

Avoid storing the only copy of both the password and its recovery material in one place unless you have accepted that recovery model.

11. Rebuild sharing and emergency access#

Exports commonly represent shared data as ordinary records. They might not preserve ownership, access rules, group membership, or audit history.

Review every shared folder, collection, or vault. Confirm:

• Who owns each record
• Who should retain access
• Whether imported copies are private
• Whether changes will continue to synchronize
• Whether former members still have access
• Whether business or employer-owned data is allowed to move

Do not migrate organization-owned credentials without authorization.

Set up emergency access or account recovery again in the destination. Confirm the designated person's identity and current contact information. Explain what access they will receive and under what conditions. Do not assume that an emergency contact in the old manager automatically carries over.

12. Clean up duplicates carefully#

Only begin duplicate cleanup after the import is complete and important accounts work.

Automated duplicate detection can help locate candidates, but similar records are not always duplicates. Two entries for one website might represent different accounts, environments, family members, or historical credentials.

For each suspected duplicate:

1. Compare usernames, website addresses, custom fields, notes, and attachments.
2. Identify which record contains the current credential.
3. Merge useful metadata where the destination supports it.
4. Test the retained record.
5. Move the unwanted record to the destination's trash or archive.
6. Delay permanent deletion until the rollback period ends.

If you accidentally imported the vault twice, use import timestamps or a dedicated import folder to isolate the second batch. Verify the boundary before deleting anything.

13. Change browser and device integrations#

After verification, make the new manager the active tool on each device.

On every browser and device:

• Install the destination application or extension from its official distribution channel.
• Sign in and verify synchronization.
• Test saving, filling, and updating one non-critical login.
• Set an appropriate automatic-lock interval.
• Disable the old manager's autofill and save prompts.
• Review the browser's built-in password-saving setting.
• Remove unexpected or obsolete password-manager extensions.

Run both managers in parallel only as long as necessary. Competing autofill tools can obscure which vault supplied a credential or saved an update.

14. Use a rollback period#

Keep the old vault available for a limited verification period. Leave it read-only in practice: do not save new passwords there, and disable its autofill features.

During this period:

• Use the new manager for normal sign-ins.
• Investigate missing records as they appear.
• Verify less frequently used accounts.
• Confirm attachments and secure notes.
• Complete passkey and one-time-password transitions.
• Update the migration log without recording secrets.

Choose the duration based on how often you use the accounts in the vault. The objective is to encounter enough normal activity to expose omissions without maintaining two active systems indefinitely.

15. Delete plaintext migration files#

Do this as soon as the import is complete and you no longer need the files for troubleshooting. Do not wait until you close the old password-manager account.

Find every possible copy:

• The protected working folder
• Downloads and desktop folders
• Recently opened file locations
• Application autosave and recovery folders
• Temporary directories
• Cloud synchronization history
• Backup sets created during the migration
• Removable media
• Trash or recycle bins

Delete the export, edited copies, rejected-row files, extracted attachments, and temporary conversion files. Empty the relevant trash or recycle bin.

Secure deletion has limits. Modern solid-state storage, copy-on-write file systems, snapshots, and cloud services can retain blocks or previous versions outside the reach of a file-overwrite tool. Full-disk encryption established before the export reduces the risk from residual local data, but it does not remove copies held in backups or synchronized services.

If a plaintext export entered a cloud-synced folder, delete it from the service, its version history, trash, and every synchronized device where practical. Review the provider's retention controls. If you cannot account for the file and believe another person could have accessed it, treat the affected credentials as potentially exposed and prioritize password changes.

16. Retire the old manager#

Retire the source only after the new vault passes verification and the rollback period is complete.

Before closing or downgrading the old account:

1. Confirm access to the new vault from your intended devices.
2. Confirm that important passwords work.
3. Confirm passkeys and one-time-password codes.
4. Confirm attachments, secure notes, and custom fields.
5. Confirm sharing and emergency access.
6. Confirm that recovery materials are stored safely.
7. Confirm that plaintext exports have been removed.
8. Export any non-secret account records that you must retain, such as invoices, through the appropriate account tools.
9. Remove old browser extensions and applications.
10. Revoke old trusted devices and active sessions where appropriate.
11. Follow the source provider's account-deletion procedure if you intend to close the account.

Deleting the local application is not the same as deleting a hosted account. Read each confirmation screen and verify whether the action removes the vault, subscription, account, or only the current device.

Final migration checklist#

Do not consider the migration complete until all applicable items are true:

• The destination account has a unique password and multi-factor authentication.
• The imported category counts have been reconciled.
• Important and unusual login records have been tested.
• Passkeys have been inventoried and verified separately.
• One-time-password codes work in the destination or were reset.
• Attachments, notes, identities, and custom fields were checked.
• Shared records have the correct owners and members.
• Emergency access and recovery methods were rebuilt.
• Duplicate records were reviewed before deletion.
• Browsers and devices use the new manager consistently.
• The old vault remained available through a rollback period.
• Plaintext exports and temporary copies were removed.
• The old account was retired only after final verification.

A safe migration is complete when the new vault is usable, recoverable, and independently verified—and when the temporary plaintext created during the move has been accounted for.