How to migrate password managers without losing data

Migrating a password manager sounds simple: export from the old one, import to the new one, done. For simple vaults — one user, all standard login credentials — this description is accurate. For anything more complex — TOTP codes, secure notes with formatting, shared vault credentials, file attachments, or a vault that has accumulated years of varied content — the process requires more care than the 'export and import' description implies.

The most common migration failure mode is not technical. It is premature cancellation of the old account. Users who cancel or delete their old account immediately after importing discover weeks later that some credentials didn't transfer — either because they weren't in the export or because they were imported incorrectly. At that point, the old account is gone and the credentials with it.

The correct migration sequence — export first, keep both active during transition, verify completely, then deactivate — takes more time but avoids this failure mode.

The assumption 'CSV export captures everything' is consistently incorrect in specific categories. TOTP seeds — the secret keys that generate authenticator codes — are rarely included in CSV exports for security reasons. Bitwarden's encrypted JSON export includes them; plain CSV exports typically don't. File attachments are not exported in standard formats. Custom fields, tags, and folder structures vary in how well they transfer across different import formats. Verifying the import against the original vault before cancellation is the only reliable way to confirm completeness.

A second assumption is that the import log's success message means everything transferred correctly. Import tools report on what they were able to parse from the export file. If the export file was incomplete (missing TOTP seeds, missing attachments), the import will succeed on what it had while silently missing what wasn't there. A successful import log means the import was technically successful; it does not mean the vault is complete.

A third assumption is that shared vault credentials migrate automatically. Shared credentials in an organisation or family plan typically require separate handling — the organisation vault may need to be exported independently of the personal vault, and the recipient users may need to be reconfigured in the new system. Shared vault migration is the most complex part of any non-trivial migration.

The complete migration checklist: (1) Export from the old manager — use encrypted JSON where available rather than CSV, as it captures more fields. (2) Import to the new manager — choose the correct source format in the import tool. (3) Audit the import — spot-check 20-30 items across different types (logins, notes, cards, identities) to verify field completeness. (4) Test autofill on 5-10 sites you use regularly. (5) Run both managers simultaneously for 1-2 weeks, using the new one for all logins. (6) When confident the migration is complete, deactivate the old account. (7) Delete the export file from your device and any locations where it may have backed up (Downloads folder, iCloud, Google Drive).

TOTP migration requires separate handling: if your old manager stored TOTP seeds, check whether the export format includes them. Bitwarden's encrypted JSON export includes TOTP seeds. LastPass CSV export does not include them. If TOTP seeds are not in the export, you will need to reconfigure 2FA in the new manager by scanning QR codes from each service's 2FA settings page — a time-consuming but necessary step.

The export file is the most sensitive document created in a migration. It contains all your credentials in a format that can be read without any encryption in the case of CSV. Handle it as you would a document containing every password you own — because that is what it is. Store it only temporarily, transfer it only over encrypted connections, and delete it securely as the last step of migration.

This guide covers personal vault migration. Enterprise migrations involving SSO reconfiguration, SCIM deprovisioning from the old system, and coordinated multi-user transitions require additional planning beyond the scope of this guide.