# Migration to 4.0.1 with non-default cipher in 3 db

**URL:** <https://discuss.zetetic.net/t/migration-to-4-0-1-with-non-default-cipher-in-3-db/3419>\
**Category:** SQLCipher\
**Created:** [February 8, 2019, 2:51pm UTC](https://discuss.zetetic.net/t/migration-to-4-0-1-with-non-default-cipher-in-3-db/3419 "2019-02-08T14:51:14Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Karitsa](https://avatars.discourse-cdn.com/v4/letter/k/e9a140/32.png) [@Karitsa](https://discuss.zetetic.net/u/Karitsa)\
**Post date:** [February 8, 2019, 2:51pm UTC](https://discuss.zetetic.net/t/migration-to-4-0-1-with-non-default-cipher-in-3-db/3419/1 "2019-02-08T14:51:14Z")

</div>

I have old database which is encrypted with ‘aes-256-cfb’. Now that PRAGMA cipher is gone, how I am supposed to make migration? PRAGMA cipher\_migrate; is returning value 1. PRAGMA compatibility\_mode = 3; works ok, but ATTACH DATABASE fails (when trying to migrate with sqlcipher\_export()).

---

<div class="post-metadata">

**Author:** ![developernotes](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.zetetic.net/developernotes/32/1309_2.png) [@developernotes](https://discuss.zetetic.net/u/developernotes)\
**Post date:** [February 8, 2019, 3:58pm UTC](https://discuss.zetetic.net/t/migration-to-4-0-1-with-non-default-cipher-in-3-db/3419/2 "2019-02-08T15:58:23Z")

</div>

Hello @Karitsa

The `PRAGMA cipher` command has been deprecated [since 4/5/2016](https://github.com/sqlcipher/sqlcipher/blob/master/CHANGELOG.md#340---2016-04-05), which provided just under 3 years to migrate away prior to removal.

Given the situation where your application uses a non-default cipher, you will likely want to approach the migration process in two phases, depending on your application structure. First, you can use the 3.x version of SQLCipher to perform a custom export using [`sqlcipher_export(...)`](https://www.zetetic.net/sqlcipher/sqlcipher-api/#sqlcipher_export) to migrate from `aes-256-cfb` to `aes-256-cbc`. Once you are comfortable customers have migrated to CBC mode, you could provide a new update to your users using SQLCipher 4 where your application performs a [`cipher_migrate`](https://www.zetetic.net/sqlcipher/sqlcipher-api/#cipher_migrate) to the latest default file format. Again, depending on your application structure, you may be able to perform this routine out of band from the application itself making the upgrade process smoother for the end user.

Alternatively, you could rebuild SQLCipher 4 to utilize `aes-256-cfb` by default. While we do not recommend this approach, it is an option, but not something we support.

---

<div class="post-metadata">

**Author:** ![Karitsa](https://avatars.discourse-cdn.com/v4/letter/k/e9a140/32.png) [@Karitsa](https://discuss.zetetic.net/u/Karitsa)\
**Post date:** [February 8, 2019, 4:29pm UTC](https://discuss.zetetic.net/t/migration-to-4-0-1-with-non-default-cipher-in-3-db/3419/3 "2019-02-08T16:29:14Z")

</div>

Thanks for excellent answer, even though neither of choices are optimal. I think we check if it is possible to make a little fork to support cfb for converting to default cbc. And then after we think all users are migrated, go back to master source.