Odoo Enterprise Upgrade

Upload Your Database Dump

No file chosen

If you upload your database for testing purpose, our Quality Team will perform functional tests after it has been upgraded. During this time, your upgraded database will not be available for download.

This is normally the option you need to choose if this is the first time you upload your database for a given target version.

If you upload your database for production purpose, Our Quality Team will no longer perform functional tests on it and you will receive your database right after it has been upgraded.

You can choose this option if you already have uploaded your database for testing purpose before (for a given target version).

In previous versions (prior to 6.1), the odoo server was not using any timezone information when storing timestamp values.

From Odoo 6.1, all the timestamp values are stored in UTC (Coordinated Universal Time) and the timezone itself is set by user.

If you don't supply this information and your source database is Odoo <6.1, you'll need to convert these values yourself or contact the Upgrade Team to give that information. With this information in hand, the Upgrade Team will be able to convert these values for you with the next Upgrade request you'll ask.

Any Question ?

We will describe hereunder the 3 or 4 steps you have to follow for your database upgrade. We suggest you, as a best practice advise, to run this process minimum twice (but you can do it as often as you want): the first time, after sending us your database, you'll get it back upgraded to the version of your choice. You'll then have a period of tests, checking that data and process are still correct and working. After your tests validation, you're now ready for the effective upgrade and so you'll send us an up-to-date version of your database. We will apply the upgrade process again and you'll finally get the upgraded database to install and use in production.

We remind you that you're in charge of your database cleaning and that the upgrade warranty only concerns standard/certified modules. If you made some specific developments and want to keep them, be sure that they are grouped in a separated module. You have the choice to upgrade them yourself or ask us to do it (for more info, please contact your Odoo Account Manager or sales@odoo.com). (For further information, contact our technical team at upgrade@odoo.com or +32 81 81 37 00)

Step 1: You upload your Database

Create a backup of you database and upload it. If you need technical information about the backup procedure, please read question 2 , 3 and 4 of this current FAQ.
If your question is not answered, you can send an email message to upgrade@odoo.com and our Upgrade Team will be very pleased to answer it.

You also have the possibility to anonymize your data before uploading your database. The anonymization module is a standard Odoo module since version 6.0. If you want to anonymize your v5.0 database, you need to download it here.

Step 2: We upgrade and test your Database

Once we receive your database, we run our upgrade process and test your database.

  • If the upgrade process ended without any problem, you will receive an e-mail within a few hours, with a link where you can download your upgraded database, and then go directly to step 4.
  • If the upgrade process can not end automatically, you will receive an e-mail within a few hours, explaining that the upgrade process encountered some difficulties and that a manual intervention is necessary. More details are developped in step 3.

Step 3: We customize our Upgrade process to your database

Our upgrade process is automated as much as possible, but there can be some manual work necessary, depending on your data's complexity. It's possible that during step 2, we detect that the upgrade process can not end correctly and that we need to customize our scripts for your database. This operation may take between 1 and 2 weeks, depending on the complexity of your database. After the upgrade script adaptation, you will receive an e-mail with a link where you can download your upgraded database.

Step 4: You reinstall the upgraded Database

You can download your upgraded database and reinstall it on your new Odoo version. If you made the anonymization process at step 1, you'll have to reverse it to recover your real data.

The upgrade platform accepts a lot of different formats:
PostgreSQL custom dump, PostgreSQL tar-format, plain text sql or compressed plain text sql.

If you want to compress a plain text sql dump, you can use a variety of compression methods:
gzip, zip, rar, xz, 7zip, bzip2

If you don't really know which format to choose, see question 3.

You basically have 2 choices:

  • if you want a fast database dump and restore, choose the PostgreSQL tar-format compressed with gzip
  • if you want a small database dump file, choose the PostgreSQL tar-format compressed with xz

If you want to know how to dump/restore the format of your choosing, see question 4.

PostgreSQL tar-format compressed with gzip

commands to create
pg_dump --format=t dbname | gzip > dbdump.tar.gz
commands to restore
createdb upgraded_dbname
cat upgraded_dbdump.tar.gz | gzip -d | pg_restore -O -x -d upgraded_dbname
pros and cons
Pros:
  1. the header of a PostgreSQL tar-format dump already contains the PostgreSQL version information so, the Upgrade platform will not have to guess the version and restoring your dump will be faster
  2. Compressing using gzip method is faster than most other methods
Cons:
  1. gzip has a compression ratio that is less efficient than xz

PostgreSQL tar-format compressed with xz

commands to create
pg_dump --format=t dbname | xz > dbdump.tar.xz
commands to restore
createdb upgraded_dbname
cat upgraded_dbdump.tar.xz | xz -d | pg_restore -O -x -d upgraded_dbname
pros and cons
Pros:
  1. the header of a PostgreSQL tar-format dump already contains the PostgreSQL version information so, the Upgrade platform will not have to guess the version and restoring your dump will be faster
  2. xz has a very good compression ratio
Cons:
  1. Compressing using xz method is slower than most other methods

PostgreSQL custom dump

commands to create
pg_dump --format=c dbname > dbdump.dump
commands to restore
createdb upgraded_dbname
pg_restore -O -x -d upgraded_dbname < upgraded_dbdump.dump
pros and cons
Pros:
  1. the header of a PostgreSQL custom dump already contains the PostgreSQL version information so, the Upgrade platform will not have to guess the version and restoring your dump will be faster
  2. It's compressed by default but compression is somewhat similar to gzip compression (which is not optimal)
  3. compressing speed is relativelly fast compared to most other methods
  4. this is the default dump format used by Odoo server
    you can use the Odoo web interface to restore a PostgreSQL custom dump
Cons:
  1. the compression ratio is similar to gzip compression and so, is not the best one if you prefer a small dump file

Plain text SQL

commands to create
pg_dump -O -x dbname > dbdump.sql
commands to restore
createdb upgraded_dbname
psql -d upgraded_dbname < upgraded_dbdump.sql
pros and cons
Pros: /
Cons:
  1. there is no header in a plain text SQL file
    we will not be able to determine the PostgreSQL version you are using so, the Upgrade platform will have to guess your PostgreSQL version and restoring your dump will be slower
  2. Not compressed
    Your database dump file could potentially be huge

Beside the --format which we already covered in the previous section, you can probably use the -O and the -x options.

  • -O option means no owner information will be dumped. The upgrade platform does not use that information and is not configured with the same users than in your own Postgresql server. The owners of your database objects are skipped when we upgrade your database and the upgraded database you will receive will not contains any owner information since we also use the same option when dumping the upgraded database.
  • -x option means no access privileges will be dumped. For the same reasons than we already described about the -O option, we don't restore your database with access privileges and we don't dump these access privileges when creating the upgraded dump.

There are options that you should absolutely avoid when creating your dump.

  • -c (or --clean): automatic restoration will fail at our end and your request will be considered invalid
  • -C (or --create): automatic restoration will fail at our end and your request will be considered invalid
  • -a (or --data-only): for obvious reasons, we need the data ;)
  • -s (or --schema-only): for obvious reasons, we need the schema ;)
  • --column-inserts, --attribute-inserts, --inserts: will make the restoration process very slow

In case you are wondering if you can use an option, please ask the Upgrade Team.