← All playbooks
Password managers migration

Bitwarden → 1Password

Move Bitwarden personal and organization vaults into 1Password while using the supported importer, securing export files, and reconciling logins, rich items, TOTP, passkeys, attachments, collections, access, recovery, and integrations.

Typical timeline10–25 business days45–90 hours active work
Statusneeds review
Source testedBitwarden documentation reviewed 2026-07-19
Destination tested1Password documentation reviewed 2026-07-19
Last reviewed2026-07-19
Sources3
Before you migrate

Should you make this move?

Both platforms have a case. Compare what you gain with what you give up before scheduling the cutover.

Current platform

Bitwarden

Reasons to stay
  • Open-source foundations, broad clients, and competitive pricing offer strong value
  • Centralized credential management improves sharing, recovery, and auditability
Reasons to leave
  • Administrative polish and some enterprise workflows trail more premium competitors
  • A migration mistake can affect access to every other critical system
New platform

1Password

What gets better
  • Excellent team vaults, passkey support, and polished cross-platform clients
  • Centralized credential management improves sharing, recovery, and auditability
What gets worse
  • Premium pricing and opinionated vault organization may not suit every team
  • A migration mistake can affect access to every other critical system
Best of the move

1Password: Excellent team vaults, passkey support, and polished cross-platform clients. This removes a major source-side concern: Administrative polish and some enterprise workflows trail more premium competitors.

Worst of the move

What you lose: Open-source foundations, broad clients, and competitive pricing offer strong value. What you inherit: Premium pricing and opinionated vault organization may not suit every team.

01At a glance

Know the shape of the move.

Transfer outcome12 features audited
Transfer outcome distributionClean transfer: 0, Partial transfer: 9, Manual rebuild: 2, Not transferred: 1.
Clean0
Partial9
Manual2
Lost1
Mapping route9 of 9 fields have a destination path

This timeline assumes

  • Up to 500 users, 50 collections, and 100,000 items
  • A security owner controls both platforms, identity policy, recovery, and user communications.
  • Exports are created on a trusted encrypted device with backup sync paused.
  • A small vault containing every item type is migrated before organization-wide rollout.
  • The migration team records evidence for every blocking verification check.
02Loss matrix

What survives the move.

“Partial” and “manual” are not footnotes. They are work that must be scheduled and verified.

ItemOutcomeImpactWhat happensMitigation
Bitwarden export and import compatibilitypartialcriticalThe supported 1Password importer has format and account-setting requirements, including a documented Argon2id limitation.Run the official readiness check and pilot before organization-wide export.
Trash, Sends, and organization-owned datalosthighBitwarden exports omit trash and Sends, and personal exports do not include organization-owned items.Export each authorized organization separately and disposition omitted classes.
Attachments, passkeys, SSH keys, cards, and identitiespartialcriticalCoverage depends on the selected Bitwarden export and 1Password import path.Use the richest supported format and reconcile every item class.
Collections, groups, policies, recovery, and secrets integrationsmanualcriticalOrganization configuration is separate from vault item data.Rebuild least privilege, identity lifecycle, recovery, and machine access before cutover.
Login itemspartialcriticalWebsites, usernames, passwords, notes, and selected fields can move through supported formats.Compare counts and high-value records without exposing secret values in evidence.
Vaults, collections, and folderspartialcriticalOrganization, vault, folder, and collection models differ.Design destination ownership and sharing before import.
Custom fields and item typespartialhighRich item types and custom fields can flatten or be excluded by CSV.Use the richest supported format and test every item type.
TOTP secretspartialcriticalOne-time-password seeds may transfer as fields but must be proven safely.Test codes for a controlled sample and rotate high-risk seeds.
PasskeyspartialcriticalExport support depends on platform, operating system, format, and credential-exchange compatibility.Inventory every passkey and re-register any unsupported credential.
Attachments and documentspartialhighAttachments may require a separate archive or manual upload.Reconcile every attachment without placing it in an insecure working folder.
SSH keys, cards, identities, and secure notespartialhighNon-login items require richer formats and destination support.Test each class and preserve an encrypted source backup.
Shared access and permissionsmanualcriticalMembership, groups, policies, and item sharing do not transfer safely with personal data.Rebuild least-privilege access and test every role.
03Field and feature mapping

Where each thing goes.

SourceDestinationMethodNotes
Bitwarden account or organization1Password account or organizationmanualConfigure policy and recovery before data.
Vault, folder, or collectionDestination vault, folder, or collectiontransformApprove ownership and sharing.
LoginLoginautomaticVerify URL, username, password, notes, and favorite state.
Custom fieldDestination custom field or notetransformPreserve concealed status where supported.
TOTP secretDestination one-time passwordtransformTest current codes safely.
PasskeyDestination passkey or re-registration taskmanualUse credential exchange only where both clients support it.
Attachment or documentDestination attachment or documenttransformTransfer separately when required.
Card, identity, secure note, or SSH keyDestination supported item typetransformUse the richest supported export.
Shared membership and permissionDestination member and access rulemanualApply least privilege after import.
04Before you begin

Make the move recoverable.

Backup procedure

Create the source-of-truth backup

Preserve Bitwarden data, configuration, and operating evidence before any destination write.

  1. Create an encrypted administrative backup of Bitwarden personal and organization vault data.
  2. Inventory item types, folders, shared vaults, attachments, passkeys, users, groups, policies, and integrations without logging secrets.
  3. Record counts by ownership, item type, access group, attachment, and unsupported class.
  4. Pause backup sync before any plaintext export and record secure deletion responsibilities.

Proof to capture: A signed manifest reconciles every scoped record class, runtime dependency, export file, count, and hash.

Transformation · Encrypted inventory and migration workbook

Vault and access map

Separate personal and organization ownership and rebuild least privilege.

  1. Inventory source values and exceptions.
  2. Define explicit destination mappings.
  3. Reject unmapped critical records.

Proof to capture: Save the input, output, command or tool settings, warnings, and final item counts.

Transformation · Official exporter/importer and secure verification checklist

Rich-format import and exception ledger

Transfer supported items without silently dropping secret classes.

  1. Normalize encoding, dates, identifiers, and blanks.
  2. Run a representative pilot.
  3. Reconcile accepted, rejected, and transformed rows.

Proof to capture: Save the input, output, command or tool settings, warnings, and final item counts.

05Handle with care

The things most likely to hurt.

These are operating limits. Treat every “Stop if” condition as a blocked migration, not a suggestion.

Export

Plaintext exports leak secrets

criticalpossible likelihood

An unencrypted file reaches cloud sync, backups, email, logs, or another user.

Consequence
The entire credential set is compromised.
Mitigation
Use the richest secure transfer path, isolate plaintext, and rotate if exposure is possible.

Stop if: The working file cannot be accounted for and securely deleted.

Import

A successful import omits high-risk item types

criticalpossible likelihood

Counts look plausible while passkeys, TOTP, attachments, or shared items are absent.

Consequence
Users are locked out or retain unsafe source dependence.
Mitigation
Reconcile by item type and test controlled credentials.

Stop if: Any critical credential lacks a verified destination or re-registration task.

Access

Source and destination sharing differ

criticalpossible likelihood

Imported items land in personal or broadly shared containers.

Consequence
Secrets become unavailable or overexposed.
Mitigation
Build and test destination access before organization rollout.

Stop if: Any test user gains unauthorized secret access.

06Precise timeline

Do the work in this order.

Estimate forUp to 500 users, 50 collections, and 100,000 items
Total elapsed10–25 business days
Active work45–90 hours
BufferAdd time for Argon2id import constraints, many attachments, passkeys, multiple organizations, SSO, SCIM, or Secrets Manager.
01
Days 1–3Inventory and decisions2–3 days
02
Days 3–5Backup and reconcile1–3 days
03
Days 5–12Map and pilot3–8 days
04
Days 10–20Final delta and switch1–5 days
05
Days 12–40Observe and close3–10 days
  1. Days 1–3 · inventory

    Inventory and decisions

    6–12 hours active2–3 days elapsedOwner review waiting
    • Inventory Bitwarden data, features, users, domains, and integrations.
    • Approve scope, owners, mappings, and exclusions.

    Depends on: Bitwarden and 1Password administrator access

    Stop / go checkpoint

    Export?

    Go when: Every critical item has an owner and disposition.

    Stop when: Consent, billing, access, or system ownership is unclear.

  2. Days 3–5 · backup

    Backup and reconcile

    5–10 hours active1–3 days elapsedExport processing waiting
    • Create immutable exports and configuration evidence.
    • Reconcile counts, totals, and hashes.

    Depends on: Approved inventory

    Stop / go checkpoint

    Transform?

    Go when: Source totals and export manifests agree.

    Stop when: Any critical dataset or configuration is absent.

  3. Days 5–12 · pilot

    Map and pilot

    10–35 hours active3–8 days elapsedDestination processing and review waiting
    • Configure 1Password and transform representative data.
    • Run a pilot containing normal records and every critical edge case.

    Depends on: Verified backup

    Stop / go checkpoint

    Scale?

    Go when: Pilot mappings, behavior, access, and evidence pass.

    Stop when: Any critical check fails or produces unexplained variance.

  4. Days 10–20 · cutover

    Final delta and switch

    5–25 hours active1–5 days elapsedDNS, import, or sync propagation waiting
    • Freeze production writes in Bitwarden.
    • Apply the final delta, switch ownership, and run blocking checks.

    Depends on: Passed pilot and approved rollback

    Stop / go checkpoint

    Open production?

    Go when: Counts reconcile and one destination system owns production.

    Stop when: A source writer remains active or a blocking check fails.

  5. Days 12–40 · observe

    Observe and close

    3–18 hours active3–10 days elapsedOperating-cycle evidence waiting
    • Monitor one complete operating cycle.
    • Sign the verification report and close rollback only after stability.

    Depends on: Verified cutover

    Stop / go checkpoint

    Close rollback?

    Go when: No trigger occurs during the agreed observation period.

    Stop when: Data, access, delivery, routing, or business results regress.

07The point of change

Cut over with a way back.

Go live

Cutover

Make 1Password the only production system without losing the final Bitwarden delta.

Recommended window: A low-volume weekday morning with platform, data, DNS, and business owners available.

  1. Freeze production writes and scheduled actions in Bitwarden.
  2. Export, transform, and reconcile the final delta.
  3. Apply the approved delta to 1Password.
  4. Switch domains, forms, integrations, sending, or sync ownership as applicable.
  5. Run every blocking verification check and keep the source intact.

Proof to capture: 1Password owns production, totals reconcile, and every blocking check has durable evidence.

Return to safety

Rollback

Return production ownership to Bitwarden without losing destination-era changes.

Deadline: Within seven days and before source data, plans, credentials, domains, or billing are changed.

  1. Stop new writes and scheduled actions in 1Password.
  2. Restore the prior Bitwarden routing, forms, integrations, sending, or sync ownership.
  3. Export the 1Password post-cutover delta.
  4. Review and apply safe destination-era changes to Bitwarden.
  5. Run the same blocking checks against the restored source.

Proof to capture: Bitwarden again owns production with current data and no duplicate destination action.

Rollback immediately when
  • Unexplained critical count or value variance
  • Missing or exposed critical data
  • Duplicate production action
  • Failed access, routing, delivery, or integration check
  • A critical feature has no safe destination replacement
08Verification report

Prove the migration worked.

Every blocking check must pass. Capture the evidence before cleanup begins.

0%
Interactive report preview0 / 8 checks passed
PassIDCheckMethodExpected resultEvidence
V-01BlockingItem reconciliationCompare counts by owner, vault, folder, item type, and attachment.Every scoped item is imported or has a re-creation task.Count ledger without secrets.
V-02BlockingCredential operationTest a controlled high-risk and stratified account set.URL, username, password, and autofill work as approved.Redacted test log.
V-03BlockingTOTP and passkeysExercise controlled TOTP and passkey credentials.Every tested credential works or is re-registered.Redacted MFA report.
V-04BlockingFields and item typesInspect every item class and custom-field pattern.Required values and concealment are preserved.Type matrix.
V-05BlockingAttachments and documentsCompare counts and open controlled files.Every required attachment is present and protected.Attachment ledger.
V-06BlockingVault and collection permissionsTest representative members, groups, admins, and leavers.Least privilege matches policy.Access evidence.
V-07BlockingEnrollment and break glassRehearse new-device, recovery, and offboarding paths.Approved recovery objectives pass.Recovery report.
V-08BlockingExport deletion and source freezeAccount for working files, backups, clients, policies, and integrations.1Password is authoritative and plaintext exports are securely deleted.Security sign-off.
09Post-migration cleanup

Remove the scaffolding safely.

Safe after: One complete operating cycle, at least seven stable days, and owner sign-off on every blocking check.

  1. Create final Bitwarden exports and archive verification evidence.
  2. Revoke temporary credentials, API keys, webhooks, and elevated roles.
  3. Remove obsolete embeds, forms, jobs, integrations, and DNS records.
  4. Keep the source intact through the approved retention window.
  5. Cancel paid plans only after billing, legal, and recovery review.
  6. Schedule the next 1Password backup, access, and migration-playbook review.
Sources and maintenance

Built to be reviewed.

Tested 2026-07-19. Next scheduled review: 2026-10-19.

  1. 1Password: import from BitwardenAccessed 2026-07-19
  2. Bitwarden: export vault dataAccessed 2026-07-19
  3. 1Password: import from other applicationsAccessed 2026-07-19