Quick Answer
To switch password managers, prepare the destination and recovery route, move supported items, then verify sign-in and shared access before retiring the old vault. Prefer a compatible direct transfer; protect any export file. Passkeys, attachments and verification-code secrets need their own checks, and an import confirmation does not prove the move is complete.
A move can involve more than passwords. Passkeys, verification-code secrets, attachments and shared access need separate checks. Keep the old manager intact until you know that everything you rely on works in the new one.
1. Prepare the New Account and Recovery Route
Install the new manager from its official source and confirm that it supports your devices and browsers. Set up its account protection and recovery options before adding your whole vault. If you are moving work credentials, follow your organisation’s approved process.
- Choose a strong, unique account password where required and enable supported MFA.
- Store recovery information somewhere accessible without unlocking the new vault.
- Confirm you can sign in on the devices you intend to use.
- Decide which vaults belong to you and which are shared or organisation-owned.
Different providers use different recovery mechanisms. For instance, 1Password’s Secret Key has a different role from a two-factor recovery code. Do not assume that a backup email or one saved code can recover everything.
2. Make an Inventory Before Moving Anything
Record approximate counts by type, without copying secret values into an ordinary checklist. Include logins, notes, payment details, identities, documents, passkeys and stored verification codes. Note who uses shared items and which services are essential.
Also check archived items and any data stored in a separate authenticator app. A password-manager export will not automatically collect secrets from unrelated apps. Keep a short list of items you must verify individually, such as email recovery and business administration accounts.
3. Choose a Transfer Method Both Apps Support
Use the documentation for your exact source, destination and operating system. “Supports credential exchange” does not mean every pair works in both directions.
Direct Transfers on Android
Google’s September 2026 Android announcement describes transferring passwords and passkeys without creating an export file. Start the import in the destination app, select an available source and authorise the selected items.
Google lists Google Password Manager, 1Password, Bitwarden and Dashlane as participating providers, but app-specific limits still apply. For example, Bitwarden’s current import guide requires Android 14+ for its direct import and says Dashlane-to-Bitwarden importing through that Android route is unsupported. Check the direction you need before relying on it.
Direct Transfers on iPhone
Compatible apps can use credential exchange on iOS 26 or later. For example, Bitwarden documents an iOS import route that begins in the compatible source app’s export flow and selects Bitwarden as the destination. Update both apps and inspect the selected item types. This does not establish that every source can transfer to every destination.
File Export and Import
When direct transfer is unavailable, choose the richest export format your destination explicitly supports. CSV is widely used for passwords, but it may leave out other records or fields. For example, 1Password documents narrower coverage in CSV than in its 1PUX export. Its current guide limits passkey export to the iOS and Android apps; a desktop 1PUX export is not a substitute for that passkey transfer. Check the source’s exact platform and version.
Not every export is encrypted. CSV, plaintext JSON and unencrypted archive formats can expose secrets to anyone who can read the file. Some managers offer encrypted exports, but a proprietary backup is not necessarily importable elsewhere. Bitwarden’s export documentation distinguishes plaintext, encrypted and attachment-containing options.
- Export only on a trusted, updated device.
- Save the file to a private local folder that is not automatically synced or shared.
- Import it promptly using the destination’s matching source format.
- Do not email the file or send it to an online converter, support chat or AI tool.
- After checking the import, delete the temporary export and remove accessible copies from Trash or Recycle Bin.
If you discover that a plaintext export was publicly shared or accessed by someone else, treat the included secrets as compromised and prioritise replacing them. Accidental storage in your private cloud account is not proof that an attacker read it, but you should remove unnecessary copies and assess who could access them.
4. Check the Items That Commonly Need Extra Work
- Passkeys: use a supported transfer or format. Where migration is unavailable, add a new passkey through the service’s account settings while your old sign-in still works.
- Verification codes: determine whether the secret that generates time-based codes moved. Some formats include it; others do not. Test before removing the old method.
- Attachments and notes: open a sample of each type and compare fields. A login record can arrive without its attached document.
- Shared access: check permissions and ownership. Copying an item into your private vault does not automatically recreate family or team sharing.
Do not assume that every JSON file transfers passkeys. Bitwarden’s own JSON export can contain them, but another manager may not understand the format. A file extension is not an interoperability guarantee. If you are replacing a phone, use our passkey recovery guide to check the original storage provider and preserve a working sign-in route.
If a code-generating secret did not transfer, follow that service’s supported process for changing authenticators. Keep a recovery method available; do not disable your only working second factor simply to tidy up the old app.
Decide Whether You Need a New Provider or a New Version
A device replacement, account-region move and provider change are different jobs. Adding another phone to the same synced account may require only the provider’s supported sign-in and recovery process, rather than an export. An old app losing support may call for an upgrade instead of a different subscription. For example, 1Password says version 7 will retire in early 2027; its guidance points customers to version 8. That is a version-specific change, not evidence that the 1Password service is being discontinued.
Before committing to a destination, check the tasks you actually need: a mixed-device household, a specific browser, shared records, an attachment workflow or recovery help. Open its current import documentation for your source. A low price or a familiar logo does not establish that your particular data will transfer. For an employer-managed vault, first confirm whether you are allowed to move it and which organisation must own the result.
Treat Passwords, Passkeys and Sessions as Different Things
Copying a saved password into a new vault does not change the password at the website. If the old copy was exposed, migration alone does not make it secret again. Change that credential through the service’s genuine settings, save the new value in the current manager, and review account sessions and recovery details where compromise is suspected. Do not repeatedly overwrite a working new record with a stale export.
For a passkey, establish whether the supported workflow transferred an existing credential or you registered an additional passkey at the service. After a transfer, avoid deleting a website’s passkey registration merely because it looks old: the migrated copy may use that registration too. If you registered a separate replacement, verify it through the service before removing an unneeded older credential. Deleting a vault item and managing the service’s registered sign-in methods are separate actions.
A successful session already open in the browser can hide an incomplete move. Check a fresh sign-in through a trusted device or browser context while retaining a separate working session and recovery route. Do not sign every device out just to prove that a migration worked. When the service asks for an extra factor, confirm whether the code, recovery key or hardware authenticator is still available independently of the old manager.
Handle Changes Made During the Migration
Choose a short, practical period for the transfer and tell authorised users where to save changes. If you exported on Monday but changed an email password on Tuesday, that Monday file cannot contain Tuesday’s value. Use the current service and the agreed active vault to resolve the difference. A repeat import can create an older duplicate instead of updating the corrected record.
| Change during the move | What to reconcile | Keep available |
|---|---|---|
| A password was reset after export | The working value in the intended current vault. | A trusted service session and recovery route. |
| A shared item was edited | The current value, owner and authorised recipients. | Access from a member’s own account. |
| A passkey transfer was unavailable | A supported additional sign-in method at that service. | The original credential until the replacement works. |
When you need to pause, keep both accounts protected and make the exception list specific. Resume by resolving those affected items, rather than importing the entire old vault again. Once the new workflow is established, disable unwanted old save prompts on each device. Check the next real password change lands in the correct manager; installing a new app alone may not change every autofill or save setting.
Pilot the move and choose one current copy
Before moving a household’s entire vault, choose a small representative set of items: a simple login, one with a note, a shared item and a credential type you particularly depend on. Check the destination’s supported workflow rather than assuming that it can import an arbitrary selection. The aim is to expose a format or permission problem while the original remains available, not to create a second live vault that everyone edits indefinitely.
Agree which manager receives new passwords during the move. If you reset a password at a service after exporting the old vault, the export still contains the previous value. Record that account as needing reconciliation and save the working credential in the chosen current manager. Do not restore an older export over a newly corrected record merely to make counts agree. When two copies differ, verify the actual service through a trusted session and update the intended record.
A family move also needs a named owner for each shared item. Decide whether the destination item belongs in a private vault or a family collection, then check access from an authorised member’s own account. Copying a login does not carry over every permission. Keep personal recovery email, financial details and an adult’s private accounts outside a broad family share. For work-owned records, stop at the employer’s permission boundary rather than using a personal export as a shortcut.
For a move between Bitwarden accounts, regions or hosted servers, inspect the export type before deleting anything. An account-restricted encrypted export is tied to its originating account; it cannot be restored to a new account with the same email. A password-protected export serves a different portability purpose. Follow the encrypted-export guide and confirm destination support rather than treating “encrypted” as “works everywhere.”
Use a brief exception list for items that did not move cleanly. Record the item name, what is missing and the supported next step without copying secret values into the list. Resolve essential account access before less urgent tidying. Repeatedly importing the same full file can create duplicates and make the exception list harder to trust; check the destination’s import result before retrying.
Finally, review device settings and household habits. A phone may still save a changed password into its former provider even after the new app is installed. Turn off the obsolete save prompts once the new workflow works, tell authorised family members where shared logins now live, and check the next password change lands in the intended vault.
5. Test Sign-In, Autofill and Recovery Access
- Compare item totals and inspect the username, website and password fields in several records.
- Test a few low-risk accounts first, then essential services such as email and the accounts used for recovery.
- Check transferred passkeys and verification codes separately.
- Confirm that authorised family members or colleagues can reach their shared items.
- Set the new manager as your autofill provider on each device and confirm it works.
Use a fresh sign-in on a trusted device while retaining an existing working session. This tests more than opening a record in the vault. Avoid repeatedly attempting a failing password against an account with lockout controls.
If you are moving into Bitwarden, our Bitwarden import guide covers the exact routes and duplicate-import pitfalls.
6. Retire the Old Manager After Verification
Keep the old vault protected and available during the transition. Avoid saving new passwords into both managers, which can leave you unsure which copy is current. Turn off the old autofill or save prompts once the new setup works, without immediately deleting the old data.
Only close the old account when you have confirmed all required data, shared access, passkeys and recovery routes. Check subscription cancellation separately from account deletion. Uninstalling an app does not necessarily cancel billing or remove a cloud account.
There is no universal number of days to wait. Completion depends on verification, not the calendar. For ongoing protection after the move, see how to use a password manager more safely.
Finish with a verified cutover
Keep one clear current vault, a working recovery route and an explicit list of any remaining gaps. Retire the old account only after the required credentials and shared access work on the devices you use. If the transfer is incomplete, fix that specific problem before deleting the source; subscription cancellation is a separate task.
Frequently Asked Questions
Do I need to recreate every passkey?
Not always. Supported direct transfers and some formats can move passkeys. If your exact app pair cannot, add a new passkey at each service while the old sign-in remains available.
Should I delete my old account after the import says complete?
No. First verify important logins, item types, shared access, passkeys and recovery. An import confirmation does not establish that everything you need transferred correctly.
Will my verification codes transfer?
It depends on the source, format and destination. Some transfers include time-based-code secrets and others do not. Test the new codes or use the service’s supported authenticator-change process before removing the old method.
Does moving a password change it on the website?
No. Copying a saved credential does not reset the service’s password. If it was exposed or reused, change it through the service and save the working new value in the current manager.
Should I remove an old passkey at the website after transfer?
First establish whether the transfer copied an existing credential or you registered a separate replacement. The migrated copy may still use the existing registration. Verify the supported new sign-in before removing any registration or your only working credential.
Sources and Image Credits
Sources: Google’s September 2026 Android credential-exchange announcement; Bitwarden import methods and platform limits; export coverage; encrypted export scope; 1Password export and version guidance; 1Password Secret Key.
Illustrations: Impulsec.
Share this article
