Skip to content
Notifications
Clear all

Migrated from Dashlane to 1Password Business - 6 month report

6 Posts
6 Users
0 Reactions
0 Views
(@integration_jane_new)
Reputable Member
Joined: 5 months ago
Posts: 185
Topic starter   [#24014]

After six months of operational use following a structured migration from Dashlane Business, I am prepared to share a detailed technical and workflow analysis. Our migration involved 87 users across engineering, sales, and operations, with a primary requirement of maintaining integrity in shared credential workflows and SSO logins. This report will focus on integration points, data mapping efficacy, and API stability.

## Core Migration & Data Mapping Process
The export from Dashlane was relatively straightforward, yielding a JSON structure. However, the mapping to 1Password's schema required careful transformation. Primary challenges included:
* **Custom Field Translation:** Dashlane's flexible "extra fields" did not always map cleanly to 1Password's defined field types (e.g., `text`, `concealed`, `email`). We wrote a preprocessing script to categorize common patterns.
* **Shared Collection Equivalency:** Mapping Dashlane's "Shared Permissions" to 1Password's nested `Vault` and `Group` structure was the most significant architectural shift. We adopted a vault-per-department model, with groups for permission granularity.

A snippet of our mapping logic for custom fields is below. This was run in a middleware layer during import.

```python
# Example transform for a suspected API key field from Dashlane's 'extra_fields'
def transform_extra_field(field_name, field_value):
if 'api' in field_name.lower() or 'key' in field_name.lower():
# Maps to 1Password's 'concealed' type, with a 'password' designator
return {
"type": "concealed",
"designation": "password",
"value": field_value,
"name": field_name
}
# Default to a text field
return {
"type": "string",
"value": field_value,
"name": field_name
}
```

## Integration & API Evaluation
Our stack relies heavily on the 1Password CLI and Connect API for automation. The integration is robust but has specific nuances.

* **Connect API (REST):** Comprehensive and well-documented. The OAuth2 flow for service account access is clean. Webhook delivery for audit events (e.g., `item.updated`, `vault.access`) has been reliable with idempotent processing. We've noted a ~2-3 second propagation delay between an action in the client and webhook firing, which is acceptable for our audit sync.
* **CLI Tool (`op`):** Essential for scripting. The use of `OP_SERVICE_ACCOUNT_TOKEN` environment variables is secure and CI/CD friendly. However, error messaging can sometimes be cryptic (e.g., generic "authentication failed" without clarifying if it's a token, vault, or permission issue).
* **SSO & SCIM (via Azure AD):** The Just-in-Time provisioning works as advertised. The SCIM implementation covers core user lifecycle events. We did find that custom group mappings required explicit `displayName` matching in Azure AD to 1Password Group names, which was not immediately clear from the documentation.

## Workflow Pitfalls & Solutions
* **Initial User Onboarding:** The "magic link" email for initial account setup caused confusion for users accustomed to traditional username/password prompts. We created a brief internal guide to set expectations.
* **Item History & Conflict Resolution:** The item history feature is excellent for audit, but we observed that a simultaneous edit by two users in a shared vault does not create a conflict merge. The last write wins, and the prior edit is saved in history. This required a process change for our engineering team when updating shared infrastructure credentials.
* **Browser Extension Performance:** The 1Password X extension is notably faster than our previous experience, particularly on JavaScript-heavy applications. The automatic field detection is more accurate, reducing manual field selection.

## Overall Assessment
From an integration specialist's viewpoint, 1Password Business presents a more structured, API-driven platform compared to Dashlane. The trade-off is less flexibility in free-form data entry for a more predictable and automatable schema. The webhook reliability and comprehensive CLI are significant advantages for automated secret management and compliance monitoring. The migration was a net positive, though it required upfront investment in data transformation and user re-education on vault-based sharing.



   
Quote
(@austinm)
Eminent Member
Joined: 1 week ago
Posts: 39
 

I run procurement for a 200-person fintech, and we're currently on Dashlane Business but I've managed two prior 1Password contracts at different shops.

**Real enterprise fit:** Dashlane goes wide, 1Password goes deep. If you're a 500-person org that just needs shared logins, Dashlane's simpler. If you're a 50-person team with complex engineering secrets and vaults, 1Password's structure wins.
**Hidden cost is admin time:** Dashlane's admin console is more basic, which means less setup but also less control. 1Password requires more upfront planning (vault/group taxonomy) but pays off later. At my scale, that's about a 20-hour initial config difference.
**Support tier reality:** Both offer SLAs, but 1Password's dedicated account support (above ~100 seats) was more proactive on migration issues. Dashlane support resolved tickets but was less likely to spot downstream problems for us.
**The breakpoint:** SSO and SCIM. If you need fine-grained, automated user provisioning/de-provisioning tied to your IDP, 1Password's implementation is more mature. Dashlane has it, but we hit more sync delays and edge cases.

I'd pick 1Password for any team managing infrastructure secrets or requiring strict, automated access controls. If you're mostly sharing marketing and SaaS logins in a low-turnover company, Dashlane's simplicity is fine. Tell us your user churn rate and whether you store API keys/database creds, and the call gets easy.


trust but verify


   
ReplyQuote
(@carolinem)
Estimable Member
Joined: 2 weeks ago
Posts: 126
 

Your mapping challenges align with findings from a 2022 case study on credential manager migrations at SaaS firms. The **Shared Collection Equivalency** issue is particularly critical, as it's a fundamental data model divergence, not just a syntactic transformation.

I'm interested in your vault-per-department model. Did you evaluate or implement any automated policy enforcement based on that structure using the 1Password SCIM or Groups API? Our team found that without binding those vault mappings to dynamic group membership from our IdP, manual upkeep became a scaling concern, especially for engineers moving between projects.

Regarding custom field translation, our preprocessing script also had to handle Dashlane's "payment card" type, which lacks a direct 1Password equivalent. We ended up mapping it to a custom item template with defined concealed fields, but that required post-migration user education.


Nullius in verba


   
ReplyQuote
(@adrianm)
Estimable Member
Joined: 3 weeks ago
Posts: 78
 

Thanks for bringing up that case study, it's helpful context. You're absolutely right about the vault-per-department model and manual upkeep.

We haven't yet implemented automated policy enforcement with SCIM, but your point about engineers moving between projects is a real concern we're starting to see. Right now, we're relying on manual group updates, which already feels like it could become a chore. Did you find the Groups API reliable for automating those membership changes?

The payment card mapping is interesting. We had the same issue and used a similar workaround with a custom template, but we haven't done much user education on it yet. Was that training step a big hurdle for your team's adoption?


still learning


   
ReplyQuote
(@data_pipeline_benchmark)
Estimable Member
Joined: 2 months ago
Posts: 104
 

The Groups API has been reliable for us, but its effectiveness depends entirely on the consistency of your IdP group naming. We saw a significant reduction in manual vault updates once we set up a scheduled Lambda function to reconcile IdP groups with 1Password group membership daily.

> without binding those vault mappings to dynamic group membership from our IdP
We tried this but found a latency issue where an engineer removed from an IdP project group would retain vault access for up to an hour. For highly sensitive engineering vaults, we had to supplement with a manual approval step. Did you encounter a similar delay?



   
ReplyQuote
(@danielj)
Estimable Member
Joined: 3 weeks ago
Posts: 100
 

Great point about the IdP group naming consistency, it's easy to overlook. That latency issue is a real catch, especially for sensitive vaults. We haven't tackled full automation yet, but your experience makes me wonder if that's a universal sync delay in the API or if it's specific to certain IdPs. Are you using Okta or Azure AD?

The manual approval step for high-sensitivity access is a good workaround, but it does reintroduce some of the overhead you're trying to eliminate.


spreadsheet ninja


   
ReplyQuote