Why 1-click password manager migration doesn't exist in 2026

"Can I migrate from [competitor] in one click?" is one of the most common questions vendors hear on sales calls, especially right after a competitor's breach makes headlines. Vendors present one-click migration as a convenience feature. In enterprise environments, it's only the starting point.

A working password manager migration recreates vault hierarchy, ownership, permissions, service accounts, automation, and integrations. The quality of that reconstruction decides whether users, applications, and infrastructure keep operating securely after cutover.

Verizon's 2026 Data Breach Investigations Report found that 39% of System Intrusion breaches involved stolen credentials, while 84% involved servers. As password managers become part of the infrastructure control plane, migration accuracy directly affects operational reliability and security.

This article explains why enterprise migration is an engineering project and how to run one without breaking production access on the way.

Migration starts with mapping access models

No universal import tool can accurately recreate an organization's access model, because security models rarely match between platforms.

Different password managers implement role-based access control, permission inheritance, shared vault ownership, and group membership differently. Even when two systems support the same concepts, they often implement them with different assumptions.

Consider three organizations:

• Company A organizes vaults by business function.
• Company B organizes them by product teams.
• Company C organizes them by customers and projects.

Hierarchy is only the visible part of the problem. The real challenge is translating security semantics between systems.

A source platform may inherit permissions through nested groups. The destination may require explicit assignments instead. Shared vault ownership might have no direct equivalent. An administrative role may bundle privileges that need to become multiple roles after migration. RBAC models almost never map one-to-one.

Passwork's own vault types show why. A shared company vault and a shared user vault carry different assumptions about who can see what. An importer has to make that call, not infer it from a folder name.

The same logic applies to structure handling. During import, an admin can:

• Rebuild the source hierarchy under an existing folder
• Flatten everything into one destination
• Recreate the full vault tree at the root

Each option is a deliberate choice about how the organization wants to operate going forward, and that choice depends on how the organization actually works.

A generic importer copies field values. Deciding which permissions to preserve, translate, merge, or drop requires judgment a script doesn't have.

Attackers increasingly target legitimate administrative access, exactly what's being migrated: trusted accounts and the paths that make privileged operations work. A correct migration keeps those paths behaving as intended after cutover.

Some objects can be copied, others must be redesigned

Enterprise password manager migration reshapes an organization's access model across four distinct layers: identity context, access policies, operational integrations, and trust boundaries. Each layer introduces technical constraints that a flat import file cannot represent.

The gap between copied and redesigned shows up clearly in real migration tooling. Passwork's official Bitwarden importer, for example, moves login items, secure notes, collections, folder structure, URLs, and TOTP codes automatically. It deliberately skips attachments and any item type it doesn't recognize, logging each skip instead of guessing at a mapping. That's a design decision, not a limitation: some objects can be copied safely, and some need a human to decide what happens to them.

Service accounts without clear owners, inherited permissions, obsolete integrations, and long-forgotten shared vaults fall into the second category. A successful migration preserves only what still reflects the organization's intended access model.

Any one of these handled incorrectly creates a gap: an orphaned integration, a contractor retaining production access, or an automation account authenticating against the wrong destination. None of these appear as import errors. They usually surface weeks later as incidents.

The right mental model for migration, and how Passwork applies it

Once migration is treated as an architectural transformation, the implementation naturally follows the same engineering principles used elsewhere in infrastructure projects: make every step explicit, reviewable, and reproducible.

Rather than relying on a black-box importer to interpret an organization's structure, the migration process should expose every transformation as code. Engineers should be able to inspect exported data, define how it is translated, and control exactly how every object is recreated in the destination system.

Passwork supports three migration paths, chosen by source and volume rather than by convenience:

The first two cover most real-world moves. The third makes the "transformation as code" principle visible. A migration script built on Passwork's Python connector authenticates, creates the destination vault and folder structure explicitly, and writes each item with exactly the fields the organization wants preserved:

from passwork_client import PassworkClient

passwork = PassworkClient("https://passwork.example.com")
passwork.set_tokens(access_token, refresh_token)
passwork.set_master_key(master_key)

vault_type = passwork.find_vault_type(code="company")
vault_id = passwork.create_vault("Migrated – IT", vault_type["id"])
vault = passwork.get_vault(vault_id)

folder = passwork.call("POST", "/api/v1/folders", {
    "name": "Databases",
    "vaultId": vault["id"],
})

passwork.create_item({
    "name": "Postgres primary",
    "login": "app_rw",
    "password": "...",
    "urls": ["https://db.internal"],
    "description": "Imported from Bitwarden",
    "vaultId": vault["id"],
    "folderId": folder["id"],
    "customs": [
        {"name": "TOTP", "value": "otpauth://...", "type": "totp"},
    ],
})

Nothing lands in a vault, a folder, or a permission set unless the script says so. For a full Passwork-to-Passwork move, the same logic scales to bulk REST endpoints — vaults/import, folders/import, and items/import — which return a sourceId → id map so parent objects are created before their children and every relationship stays intact.

The transformation stage is where migration becomes predictable. Engineers can encode migration rules explicitly: rename vaults, remap owners, split administrative roles, flatten inherited permissions, or exclude obsolete records altogether. Those decisions become reviewable code rather than assumptions hidden inside a generic import wizard. If the migration needs to be repeated or audited later, the transformation logic stays transparent and reproducible.

This also changes how the migration itself is secured. Traditional one-click imports typically generate an intermediate plaintext export, often a CSV, that is then processed by a generic parser with limited understanding of the destination environment. Each stage introduces its own security considerations.

If something goes wrong mid-batch, recovery is manual: delete or bin the affected vault, then re-run the script against staging. That's exactly why a dry run is worth the extra hour before a production cutover.

Validate behavior, not just imported records

Import and migration mark two separate checkpoints. Import confirms that credentials exist in the destination vault. Migration confirms that the environment behaves exactly as intended once production workloads depend on it.

A practical validation phase should answer questions such as:

• Can every authorized user access the vaults they're expected to use?
• Are unauthorized users correctly denied access?
• Do CI/CD pipelines, infrastructure automation, and API integrations retrieve secrets without modification?
• Are service accounts functioning with the expected permissions?
• Do audit logs record authentication events, permission changes, and administrative actions correctly?

These checks often surface issues that appear only after import completes. A migrated credential may sit in the correct folder while remaining inaccessible to the automation that depends on it. A role translation error may silently grant broader access than intended, passing import validation cleanly.

Passwork's activity log (events like item_imported and vault_imported) gives auditors a paper trail for exactly this kind of check, and the Security Dashboard flags weak or duplicate passwords that came along for the ride from the old vault, so they can be rotated rather than carried forward. Records missing a URL are worth a second pass too: autofill won't work on them until someone fixes the field.

Successful migration is measured by operational behavior. The destination system should enforce the same security model as before, or a deliberately improved one, rather than merely hold the same secrets.

Turning password manager migration into a security audit

Migration is often the only moment when an organization reviews every stored credential and every permission at the same time.

Day-to-day administration tends to be incremental: users are added, projects evolve, integrations accumulate, and access rights gradually expand. A migration interrupts that process and forces every object to justify its place in the new environment. That's why a structured migration often doubles as the most comprehensive access review an organization has performed in years.

During this review, teams typically discover:

• Orphaned secrets belonging to employees who left months ago
• Duplicate credentials for the same service stored across multiple vaults
• Inactive users still holding production access
• API keys that expired but were never removed
• Personal credentials stored inside corporate vaults
• Credentials for systems decommissioned long ago but never deleted

A bulk import silently carries these problems into the new platform. A transformation-based migration exposes them, because every credential, owner, and permission must be evaluated before it's recreated.

Verizon's 2026 DBIR reports that 27% of ransomware victims had evidence of an infostealer or credential leak during the previous year, and among those organizations, half were exposed within 95 days before the ransomware incident occurred. Migration is one of the few opportunities to revoke exposed or obsolete credentials before they become part of an attack chain.

The same report also notes that resolving weak passwords and permission misconfigurations across third-party cloud environments takes organizations nearly eight months on average. Doing that review during migration compresses those eight months into a planned engineering activity instead of a prolonged remediation effort.

Under GDPR Article 32, organizations must implement technical and organizational measures appropriate to the risks of processing personal data. Removing stale access and orphaned credentials during migration demonstrates those controls in practice rather than simply documenting them.

Seven steps that reduce migration risk before production

The Passwork migration workflow treats migration as an engineering project with explicit checkpoints rather than a single import operation.

1. Inventory

Document existing vaults, service accounts, integrations, automation, and external dependencies before writing any migration code.

2. Export

Extract data from the source system in a structured format. JSON is generally preferable because it preserves hierarchical relationships — Passwork's own JSON export keeps vault and folder structure intact, while CSV flattens everything into a table.

3. Review

Identify stale, duplicate, orphaned, or over-privileged credentials before they're migrated.

4. Transform

Implement migration rules that map the source environment to the destination hierarchy, ownership model, RBAC configuration, and naming conventions.

5. Test import

Run the migration against a staging environment to verify objects are created correctly before touching production. Passwork's own guidance for the Bitwarden script is explicit on this point: back up the destination database and dry-run on staging before a real cutover.

6. Validate permissions

Confirm that:

• authorized users have access;
• unauthorized users do not;
• service accounts authenticate successfully;
• CI/CD pipelines and integrations continue to function;
• audit logs capture expected security events.

7. Production migration

Execute the production migration in phases rather than one sweep — shared IT and infrastructure credentials first, then department vaults one team at a time, then private vaults once users are activated. Run the old and new systems in parallel for two to four weeks, spot-check with each department owner, and only decommission the source platform once adoption is real, not assumed.

Skipping either the testing or permission validation stages usually doesn't eliminate the work. It postpones it until production users or automated systems start failing after cutover.

Getting migration right

The easiest migrations move passwords. Successful migrations recreate how an organization operates: who owns each credential, how permissions are inherited, which systems depend on shared secrets, and which access paths should no longer exist.

One-click imports optimize for speed. Enterprise migrations optimize for correctness, auditability, and predictable behavior after cutover. Those goals rarely point in the same direction.

If there's one action worth taking before scheduling a migration, it's the first step in the workflow above: build an accurate inventory of your vaults, service accounts, integrations, and permission model before writing a single line of migration logic.

The best migration scripts document every migration decision along the way. Long after cutover, those transformation rules become a record of why access was mapped the way it was — making future audits, troubleshooting, and repeat migrations significantly easier.

Password manager migration FAQ

Data sovereignty and password management: Keeping credentials where they belong

Data sovereignty for credentials requires three controls (location, encryption, access) not just GDPR compliance. Compares on-premise, air-gapped, and EU cloud models, showing where zero-knowledge architecture like Passwork’s actually closes the sovereignty gap.

PassworkPasswork Team

Passwork’s vault policies: a CIO’s guide to enterprise security

Passwork’s Vault Types bind admin rights to the vault policy itself, not to whoever created it, closing a gap most enterprises don’t even know exists. This guide gives CIOs and CISOs a working model for vault governance, mapped to NIS2 and ISO 27001 requirements.

PassworkPasswork Team

Passwork 7.7: Secure offline mode for desktop and mobile apps

Passwords now work offline too. Passwork 7.7 brings secure offline access with full admin oversight, org-wide file attachment controls, and five new role-based onboarding guides for a smoother rollout.

PassworkPasswork Team