Your approach of a preprocessing script for custom field categorization is the right call. I've seen similar migrations where the attempt to perfectly map every 'extra field' became a rabbit hole that delayed the entire project.
Regarding the vault-per-department model as an architectural shift, that's a sound approach for permission granularity. However, its long-term maintainability hinges on your group synchronization strategy. Have you quantified the administrative overhead of managing that nested structure post-migration, especially against your original requirement for maintaining shared credential workflows? The initial mapping is only half the battle.
In our case, the static group model created a bottleneck. We had to implement a scheduled sync from our directory service to 1Password's Groups API, which added about 20 minutes of latency for onboarding or role changes. That became problematic for shared SSO logins that needed immediate access.
Latency is a liability
Yeah, the notes field cleanup was a huge time sink for us too. Your "junk drawer" point is spot on. We ended up tagging items with a `needs_review` label during the import and letting teams clean up their own vaults over a few weeks.
For a simpler mapping tool, did you look at the 1Password CLI? You can pipe a cleaned CSV through it with basic field mapping. It's not magic, but it cuts out a lot of the manual JSON wrangling if your data is already kinda structured.
Containers are magic, but I want to know how the magic works.
Your `needs_review` tagging strategy is a pragmatic compromise. We used a similar flagged-import process, but our critical mistake was not setting a sunset date for the tag, which left some items in that state indefinitely.
The CLI suggestion is a solid one for flattening simple exports. However, its effectiveness breaks down when your source data has nested custom fields or complex attachments that Dashlane's export bundles in a non-standard way. In those cases, the "manual JSON wrangling" you're trying to avoid becomes necessary just to produce a clean enough CSV for the CLI to ingest. It becomes a two-step process anyway. Did you encounter that limitation?
Data over dogma
The shared credential workflow definition was the first phase of our migration and the most critical. We used a three-step process: first, an audit script on the Dashlane export that identified items with multiple distinct user email associations in the shared folder logs. Second, we conducted stakeholder interviews with team leads from sales and support to validate that list and document the specific use case for each shared item. Third, we modeled the permissions as a directed graph before any group creation in 1Password, which exposed the cross-departmental dependencies clearly.
The tooling was basic, but effective. The audit script was custom Python, parsing the activity logs from the admin console export. For the graph modeling, we used a simple Python script with `networkx` to output a visual, but even a spreadsheet matrix of items-to-teams would serve the same purpose. The key was having a documented map of requirements before touching the 1Password admin console.
Without that graph, you'd be designing your group structure based on an incomplete picture. For example, we found a "CRM Sandbox" credential used by both sales onboarding and support for bug replication, which created an edge case requiring a separate, cross-departmental vault that didn't fit the initial department model.
Regarding the preprocessing script, it handled about 80-85% of cases cleanly. The primary manual cleanup wasn't for custom fields but for item categorization. Dashlane's export doesn't distinguish well between, for example, a database connection and a website login when both use a username and password. We had to build a secondary classification layer using URL patterns and keywords.
> Did you find your preprocessing script handled most cases, or was there still a lot of manual cleanup after the import?
The real manual effort was the 15% of items where custom fields contained procedural notes or one-time codes. We moved those to the item's notes section during import and applied a specific tag. The team then reviewed tagged items over the following month. The script's success metric wasn't perfection, but minimizing the number of items that would break a user's workflow immediately post-migration.
A caveat: our script was strictly rule-based. We considered probabilistic classification but deemed the maintenance of a training set for our relatively small dataset to be overhead with diminishing returns. The rules were based on explicit field names in the Dashlane JSON and a mapping table we built during the audit phase.