Restoring Bitwarden creation/revision timestamps after migrating to Vaultwarden

[Druxtt]

When I migrated from a Bitwarden Premium account to my self-hosted Vaultwarden instance, I used the standard export/import workflow — which worked perfectly for all credentials. However, I noticed something frustrating: all my Created and Revised timestamps had been reset to the import date. 566 entries, all showing the same timestamp.

This is a known issue reported by several users. Even though Vaultwarden is Bitwarden-compatible and both export formats share the exact same JSON fields (creationDate and revisionDate), the import process simply ignores them.

Since those timestamps were meaningful to me (knowing when a credential was first created or last changed), I decided to restore them by patching the SQLite database directly.

---

The approach

Both the Bitwarden and Vaultwarden JSON exports contain creationDate and revisionDate. The problem is that entry IDs and folder IDs differ between the two vaults — so a direct mapping isn't possible. Instead, I wrote a Python script that:

1. Merges WAL files before touching the database
2. Matches entries between the two exports using (folder_name, name, username) as a composite key
3. Detects and reports ambiguous matches (duplicates) for manual review
4. Generates a SQL file with UPDATE statements
5. Applies the changes in a single atomic transaction

The script also creates an automatic backup of the database before doing anything.

---

One gotcha: the timestamp format

This took a few attempts to get right. The format Vaultwarden actually stores in SQLite is:

2023-03-05 12:38:36.496000000

That's 9-digit nanoseconds, no UTC suffix. Both 603000 UTC (microseconds + suffix) and 603 UTC (milliseconds + suffix) caused Vaultwarden to panic on startup with a deserialization error. Worth knowing if you ever write to the ciphers table directly.

---

Results

Out of 571 Vaultwarden entries:

• 561 timestamps cleanly restored
• 1 ambiguous match (duplicate entry I was going to delete anyway)
• 8 unmatched entries — all credentials I had created directly in Vaultwarden after the migration, so they had no Bitwarden counterpart

Pretty clean outcome.

I can share the python script if anyone would need it

---

Hope this helps someone. And if Vaultwarden ever adds native timestamp preservation on import, this whole workaround becomes unnecessary — would be a nice quality-of-life addition!

[kpfleming]

Export and import are done by the client, not by the server, so it may not be possible for Vaultwarden to change this behavior.

[Delicates]

Because the BW server-client protocol seems to be not fit for purpose when it comes to passwords import, I also decided to look for a direct database load solution. In my case I want to load Firefox password extracts, and this date data loss has been the main barrier to my adoption of VW. I have 16 years worth of password history that I need to import from 2 different extracts that also needs to be deduplicated.

Would be great if you can share your script.

Ideally if VW came with DB side-load tools for different extract types, we all would be happy campers.

[Druxtt]

Thanks for your feedback and for sharing your use case. I created a repo to host the script that i used, you can fount it here

I had a look at the Firefox CSV export format. Here's what I found:

Firefox seem to store timestamps as Unix milliseconds (e.g. 1781510335533), so they need to be converted before writing to SQLite. The mapping would be:

• timeCreated → created_at
• timePasswordChanged → updated_at (more meaningful than timeLastUsed for a password manager)

For the matching strategy, Firefox exports don't have an entry name or folder, so the composite key would need to shift to (domain, username) extracted from the URL, rather than (folder, name, username) used for the Bitwarden→Vaultwarden case.

I also see Firefox includes a guid per entry. For deduplication, the logic could be:

1. Exact match by guid (same entry in both files) → keep the one with the oldest timeCreated
2. Match by (domain, username) for entries without a matching guid → flag as potential duplicate for manual review

This is all doable as an additional mode in the script, we could discuss it further if you need any help

[disconn3ct]

The vaultwarden server still seems to reject those dates even if the client provides them. I hacked together a version of that script that works for 1password, but it would be a lot nicer if it were natively supported. (1p version is in the repo PRs)