Migrate SQLite databases to SQLCipher — Step‑by‑Step

Before you start

• Back up the original database (e.g., data.bak.sqlite) and keep it offline.
• Optionally compute and store a checksum (SHA‑256) to verify backup integrity.
• Standardize the SQLCipher parameters your team will use across databases.
• Download and extract the portable build → Download. Run it once to clear SmartScreen/AV prompts.

Migration steps

1. Create a new encrypted database — In DB Browser choose File → New Database…, set a strong passphrase, and confirm cipher parameters before saving.
2. Align SQLCipher parameters — Reopen and confirm page size, KDF and HMAC settings match your standard. Adjust via PRAGMA commands if needed.
3. Import schema and data — For small DBs, export SQL and execute on the new DB. For large datasets consider chunked CSV import.
4. Verify integrity — Close and reopen with the same key; browse tables, compare row counts, and run integrity checks.
5. Swap in production — Replace the old file once verified. Retain backups and update apps to use the correct passphrase and parameters.

If you encounter a “wrong key” error, see Wrong key errors and revisit SQLCipher basics — it usually indicates a parameter mismatch.

Troubleshooting & common pitfalls

• “file is not a database” — Make sure you opened the main .sqlite file (not WAL/SHM).
• “wrong key” — Ensure page size, KDF and HMAC settings match the database; confirm passphrase; see Wrong key guide.
• Performance regressions — Review PRAGMAs, run VACUUM/ANALYZE post‑import, and consider indices.
• SmartScreen/AV — Unblock in file properties or whitelist the portable EXE after first run.
• Backups & rotation — Keep encrypted backups safe; rotate passphrases periodically following security best practices.