Vaultwarden → LastPass Enterprise
Vaultwarden ↔ LastPass Enterprise: integration to migration path.
Vaultwarden deploys alongside your live LastPass Enterprise tenant and takes over one cohort at a time — there is no flag day and no org-wide cutover. Each user moves at the pace of a single ~30-minute self-service import, and in-vault TOTP seeds carry across portably, so no one re-enrols their downstream sites.
The one honest exception is a single vault-unlock factor re-enrolment per user, staggered on their first Vaultwarden login — never a mass reset. We say so up front, because the rest of this only matters if you can trust it.
The idea
Run both vaults side by side. Retire LastPass last.
The topology that makes this zero-disruption: Vaultwarden runs in production with Organizations and Collections named to mirror one cohort's LastPass Shared Folder layout, while the rest of the workforce stays on LastPass Enterprise untouched. Cohort users install Bitwarden clients pointed at your Vaultwarden URL and run a per-user export-then-import, with both extensions live during a one-to-two-week parallel run — Vaultwarden pinned, LastPass collapsed to the overflow menu. Each cohort flips its source of truth, soaks for at least 30 days, and only then is its LastPass account deactivated — and only when every cohort has cleared do we break Federated Login and terminate the contract.
The phases
Seven steps. Each one reversible.
Baseline & inventory
We enumerate each cohort's users, item and attachment counts, Shared Folder membership matrix, vault-unlock MFA factor mix, the "Disallow Export" folders that need admin windows, form-fill users and dormant accounts. Read-only against LastPass Reporting.
Stand up Vaultwarden
Vaultwarden goes live in production (HA Postgres, TLS rated A, off-box encrypted backups, a hardware-key break-glass account vaulted offline). Cohort 1's Organization and Collections are pre-built to mirror its LastPass Shared Folders. No cohort user has logged in yet.
Cohort 1 parallel run
Each cohort 1 user exports their LastPass CSV, imports it via the built-in LastPass importer, shreds the CSV from a RAM-backed tmpfs, installs the Bitwarden client and enrols a vault-unlock factor. Both extensions live, Vaultwarden pinned and LastPass collapsed.
Source-of-truth flip
The cohort is told to write to Vaultwarden only; LastPass becomes a read-only reference for 30 days with autofill disabled. Admin marks the cohort's LastPass accounts restricted — read, autofill and export only, no create or edit.
Cohort 1 vault-of-record cutover
Cohort 1's LastPass accounts are deactivated — frozen for a 30-day evidence window, not deleted — and MDM pushes an extension-uninstall. A final per-cohort audit-log snapshot is archived to your retention policy.
Repeat for cohorts 2..N
Phases 1–4 run again for every remaining cohort, scaled with the refined runbook. Long-tail dormant accounts become their own final cohort: force-reset and abandoned, their LastPass CSV preserved but not imported. Two cohorts run in parallel only after cohort 1 fully retires.
Retire LastPass Enterprise
With every cohort off, Federated Login is broken in the IdP, the SCIM API key is revoked, the final audit log is archived and the tenant is held read-only for 30 days. Then licences are cancelled and the contract is terminated.
Feature parity
Where Vaultwarden matches, and where it doesn't.
| Capability | Vaultwarden | LastPass Enterprise | Parity |
|---|---|---|---|
| Vault storage model | Vaultwarden Organizations / Collections | LP Shared Folders | At parity |
| Login / item storage | Login, Card, Identity, Secure Note items | LP Logins + typed Secure Notes | At parity |
| TOTP in vault | otpauth:// URI, fully portable | LP CSV totp column | At parity |
| Attachments | bw create attachment loop | LP attachments (not in CSV; lpass attach) | Partial |
| Time-bound sharing | Vaultwarden Send (text/file, password/expiry) | LP One-Time Password share | Partial |
| Form-fill profiles | Manual Identity re-entry (not imported) | LP form-fill profiles (not in CSV export) | SaaS only |
| KDF / key custody | Argon2id (t=3/m=64MiB/p=4), customer KMS | PBKDF2-SHA256 600k (legacy 5k–100k tenants) | At parity |
| SSO Unlock | None — master password required | LP Federated Login (IdP-derived unlock key) | SaaS only |
| SCIM provisioning | No first-party SCIM (community only) | LP SCIM Bridge | SaaS only |
| Breach monitoring | On-demand HIBP; cron + HIBP + Slack replacement | LP continuous dark-web monitoring with push | SaaS only |
| MFA at unlock | WebAuthn / TOTP / Duo / Yubico (env-var) | LP Authenticator / Duo / Yubico / TOTP | Partial |
| Recovery key escrow | None — admin reset destroys vault | LP server-mediated recovery (Federated) | SaaS only |
| Audit log | Org Events /api/events, customer retention | LP Reporting console + CSV, 1-yr | Partial |
| Compliance / SOC 2 | Customer-owned (self-hosted) | Vendor-operated SOC 2 boundary | SaaS only |
| Cost model | Self-hosted (Rust + Postgres) | ~$7/user/mo | Partial |
What we're honest about
The caveats most vendors leave out.
Federated Login has no equivalent
LastPass Federated Login replaces the master password entirely, deriving the vault-unlock key from your IdP tokens. Vaultwarden has no Trusted Devices SSO-Unlock — the master password is always required. This is the biggest architectural mismatch. We surface it before kickoff: accept the master-password UX with a hardware-key factor, front Vaultwarden with an OIDC proxy that gates the domain but not decryption, or move to Bitwarden Enterprise cloud instead if Federated Login is non-negotiable.
Dark-web monitoring stops
LastPass's continuous dark-web feed with push notifications has no Vaultwarden parity — Vaultwarden offers on-demand HIBP at password create and a Reports → Exposed view, but no continuous push. We replace it with a cron + HIBP + Slack webhook and prove it fires on a known-bad item. If your security team uses the LastPass feed actively in incident response rather than as a checkbox, that is a real workstream we estimate honestly.
CSV export drops some data
The LastPass CSV is unencrypted, so we treat it as an in-flight secret and shred it from tmpfs. Attachments are not in the CSV — they need a separate scripted lpass attach loop. Form-fill profiles do not export at all and must be re-entered manually as Vaultwarden Identity items. Server, Database and similar typed notes keep their data but flatten to Login-plus-custom-fields, losing the category label. We flag every one in the cohort pre-brief.
No recovery escrow; you own uptime
Vaultwarden has no per-user recovery-key escrow — an admin reset destroys the vault, where Federated LastPass recovery was server-mediated. We mitigate with printed master-password sheets vaulted for executives, a hardware-key break-glass account and quarterly tests. And self-hosting means SCIM, 24×7 vendor support and a managed-service backstop are gone: we run Vaultwarden HA across zones with tested backup-restore and a DR runbook with an RTO.
Why this beats a flag day
Reversible per cohort. Soaked before you commit.
An org-wide one-shot cutover is catastrophic — every user re-enrols vault-unlock MFA the same day, the helpdesk floods, and anyone who cannot unlock is locked out of every credential they own. Instead each cohort's cutover rolls back in well under an hour while LastPass is still live: uninstalling the Vaultwarden extension or lifting the LastPass restriction returns the user with no data loss, because the LastPass vault is untouched until late. No cohort advances to deactivation until it has soaked for at least 30 consecutive days with zero LastPass fallback, and the contract is only terminated after a 30-day read-only evidence window passes for the whole estate.
See whether your LastPass estate migrates cleanly.
A 30-minute call with a senior security engineer. We inventory your Shared Folders, find the Federated Login and dark-web-monitoring dependencies that decide the path, and tell you honestly what cohort-by-cohort migration looks like for your environment — before you commit to anything.
Map my migration →