Changing password managers looks like a file-transfer job. It is really an account-access migration.
Your vault may contain more than passwords: usernames, recovery codes, authenticator secrets, secure notes, attachments, payment details, shared records and passkeys may all be involved. Some of those records may transfer cleanly. Others may lose fields, remain tied to the old service or require new enrollment at each account.
That makes a successful import an intermediate result, not proof that the move is complete. The safer sequence is to inventory what you depend on, establish a recovery route, migrate in stages, test actual sign-ins and keep a controlled path back until the new setup has proved itself.
This guide is deliberately vendor-neutral. Export formats, passkey handling, account deletion and recovery policies vary by product, platform and version. The supplied research did not include the primary product documentation needed to verify those details, so instructions that depend on a particular manager must come from the current documentation for both the old and new services.
Define what must move—and what may not
Begin with the contents of the vault, but do not stop there. Record the systems around it: devices, browser extensions, mobile autofill, shared accounts, subscriptions and recovery arrangements.
A useful inventory includes:
- Passwords, usernames and website addresses
- Extra fields, tags, folders and account notes
- Secure notes and identity records
- Payment-card details
- Attachments or uploaded documents
- Recovery and backup codes
- Secrets used to generate one-time authentication codes
- Shared vaults, family collections and business records
- Emergency-access arrangements
- Passkeys
Password-manager explainers commonly describe vaults as places for passwords, authentication records and recovery codes; the supplied ICN overview is one example. That illustrates the possible scope of a vault, but it does not establish what any particular export includes.
For that, read the source manager’s current export documentation alongside the destination manager’s import documentation. Look for an explicit list of supported record types and fields. A statement that one manager can import another manager’s file is not enough if attachments, shared ownership or authentication data matter to you.
Record the product version, operating system and export method you are using. Desktop applications, browser extensions and web interfaces may not offer identical options. If the documentation does not match what appears on your screen, stop and resolve the discrepancy rather than improvising with the only available button.
Separate personal access from shared ownership
A record visible in your vault is not necessarily yours to export or reassign. Family and workplace vaults may have owners, administrators or sharing rules that survive differently—or not at all—outside the original service.
Before migrating shared records, identify who owns them, who still needs access and whether the destination can reproduce the required arrangement. For an employer-managed vault, follow the organization’s process rather than exporting work credentials into a personal account.
Build a recovery route before exporting
The moment to discover that your primary email account depends on the old manager is not after you have closed it.
Before moving data, confirm that you can access the email accounts and phone numbers used for recovery. Check the recovery settings for the old manager, the new manager and your most consequential accounts. Make sure you can unlock both vaults during the transition, including after restarting a device.
Pay particular attention to circular dependencies. Examples include:
- The new manager’s password is stored only in the old manager.
- The email account needed to reset the old manager is accessible only through the old vault.
- A one-time code required to enter an account is generated only by the system being removed.
- The sole recovery code for a manager is stored inside that same locked vault.
- A trusted device is about to be reset, sold or disconnected.
Preserve the recovery information needed to break those circles. There is no universal rule that recovery codes must always be kept inside or outside the primary vault. Keeping them together can be convenient; separating them can provide another route when the vault itself is unavailable. Choose according to the failures you need to survive, and protect any separate copy from casual access.
Do not assume authenticator data will migrate with passwords. A displayed six-digit code is temporary; the underlying account enrollment is what enables future codes. Check whether the source can export that enrollment information and whether the destination can import it. If the documentation is silent, plan to reconfigure multi-factor authentication account by account while the existing method still works.
Treat the export as a temporary liability
A portable export deserves the same care as the vault it represents, even when its filename looks ordinary.
First determine whether the supported export is an encrypted backup intended for the same product or a portable interchange file intended for another one. Those serve different jobs. An encrypted proprietary backup may be unsuitable for migration, while a widely accepted format may expose more information when opened outside the manager.
Do not infer encryption from a file extension. The source manager’s documentation should state whether the exported file is encrypted, which records it contains and what application can read it.
Use a device you control and avoid unnecessary copies. Import directly from a local location if the documented workflow permits it. Do not send the file through email, chat or a general-purpose sharing service merely to move it between two applications. Note where the browser or app saves downloads, and check whether another synchronization or backup tool automatically copies that folder elsewhere.
Before exporting, decide how the temporary file will leave your possession after verification. That plan should cover the original file, manually created copies, removable storage, cloud-synchronized folders and device backups where applicable. Deleting a visible file does not by itself prove that every replicated or backed-up copy has disappeared, so avoid creating those copies in the first place.
Choose the least revealing format that the destination officially supports, but do not convert files through an unknown website or utility simply to satisfy an import screen. If the two managers do not document a compatible route, a smaller manual migration may be preferable to handing the entire vault to an unverified converter.
Import in stages, then test real accounts
If the products permit it, begin with a small, representative set rather than making the whole vault your first experiment. Include an ordinary website login, an entry with extra fields and one record that reflects how you actually use the manager. Do not use your only route into a critical account as the first trial.
After the pilot import, inspect the records rather than counting them. Check:
- Whether usernames and passwords occupy the right fields
- Whether website addresses still point to the intended domains
- Whether notes, custom fields and tags survived
- Whether attachments are present and readable
- Whether duplicate records were created
- Whether shared records remain private or shared as intended
- Whether autofill selects the correct entry
- Whether changes synchronize to your other required devices
Then sign in normally. A record can look complete in a vault while failing because a field was truncated, an old password was imported or the website expects another authentication step.
Verify high-consequence accounts individually. Start with primary email, mobile or platform accounts used for device recovery, financial services, cloud storage and any account that can reset others. Where practical, test from another device or browser so success does not depend on a session that was already signed in.
Keep a migration log containing account names and status, but not passwords or recovery secrets. Simple labels such as “imported,” “sign-in verified,” “recovery checked” and “needs manual repair” make omissions visible.
Avoid editing both vaults indefinitely. Two active copies gradually diverge, leaving uncertainty about which password is current. Once the new manager becomes the working copy, treat the old one as a time-bounded fallback unless a failed import forces you to return.
Audit passkeys separately
Passkeys should not be treated as unusually shaped passwords. Their availability can depend on where they were created and stored, which devices or accounts synchronize them, what the website supports and whether the destination manager can receive them.
The supplied PassHulk migration article makes the limited but useful point that moving an account population to passkeys is not necessarily one bulk operation. It does not establish compatibility among specific managers or platforms. Likewise, an app-store listing may advertise passkey storage—as the developer does for the Safe app—without proving that those passkeys can be transferred to another product.
Make a separate passkey inventory. For each important account, record:
- Where the passkey appears to be stored
- Which devices can currently use it
- Whether the account allows another passkey to be added
- Whether the old and new managers document transfer support
- Which password, recovery method or existing device remains available
- How an obsolete passkey can be identified and removed later
When direct transfer is not explicitly supported, the practical route may be to sign in using the old passkey or another recovery method, add a new passkey through the account provider and verify it before removing the old one. Follow the current instructions from the account provider and both credential managers; do not assume that one account’s procedure applies to another.
Never remove the only known working passkey merely because its label resembles an entry in the new manager. Test the replacement from the device and browser combination you intend to use.
Close the old vault only after acceptance
An import-complete message proves that a process ended. It does not prove completeness, recovery or future access.
Before cancelling or deleting the old manager, perform an acceptance review:
- Priority accounts accept credentials from the new manager.
- One-time authentication and recovery methods still work.
- Passkeys have been tested separately.
- Required records appear on every device you intend to use.
- Shared users can access the correct records.
- Failed, skipped and duplicate imports have been resolved.
- The temporary export and any known copies have been dealt with.
- The old subscription’s renewal and cancellation terms are understood.
- The provider’s deletion and retention policy has been read.
There is no defensible universal overlap period. Keep the old manager only as long as needed to complete verification and resolve failures, subject to its billing and account policies. Extend that period when important accounts remain untested; shorten it when the old vault itself has become an unnecessary additional copy.
Do not confuse cancelling payment, uninstalling an app, deleting a vault and closing an account. They may be separate actions. Consult the provider’s current documentation for what is deleted, what may be retained, whether there is a recovery window and what happens to shared data.
Long-term reliability and actual deletion cannot be established from an import screen—or remotely by this guide.
Choose the next manager by its next exit
A manager can make entry easy while leaving departure obscure. Before committing, examine not only what it can import, but what it promises to export later.
A useful decision card asks:
- Does it support every device, browser and account type you actually use?
- Can it produce a documented export in a usable format?
- Which fields and record types does that export omit?
- How are passkeys stored, synchronized, recovered and removed?
- Can you recover access without one particular device?
- Does sharing match your household or work requirements?
- Are renewal, cancellation and deletion terms understandable?
- Can you obtain help before an access problem becomes an emergency?
A switch is justified when the destination solves a real problem—unsupported devices, unsuitable sharing, cost, poor recovery or an inadequate exit route—and when the migration path is documented well enough to protect access.
Otherwise, keeping the current manager can be the better decision. You can also simplify the vault, remove obsolete accounts or postpone the move until the products publish compatible procedures. Staying put is not failure; moving without a proven recovery route is not progress.
Sources & methodology
This is a vendor-neutral migration framework, not a tested comparison. No first-party migration testing or auditable test record was supplied, so the guide does not claim that any particular export is complete, encrypted or interoperable.
The research package was generated on September 5, 2026 and consisted mainly of commercial or magazine-style explainers, including the ICN password-manager overview, the PassHulk passkey migration article and the Safe App Store listing. These sources were used only to identify migration questions and advertised features, not to establish product security, compatibility or superiority.
Before acting, readers should consult current, exact documentation from the source manager, destination manager, operating-system provider and relevant account provider. Product-specific instructions require confirmation of version, platform, export format, included fields, recovery policy, passkey behavior and deletion terms.
