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.