IT Q&A

Welcome!

This community is for professionals and enthusiasts of our products and services.
Share and discuss the best content and new marketing ideas, build your professional profile and become a better marketer together.

0

Migrating odoo versions on odoo.sh - notes and thoughts

Avatar
Corpuz Angel

A collection of notes and personal considerations on migrating odoo versions on odoo.sh.
Most are from personal experience and seeing what works; we can certainly do better.

General migration procedure to newer versions of odoo

  1. Create a new git repository and odoo.sh project, usually called migration-odoo<XX>-<client>; copy all custom client code and make it work for the new version of odoo; choose the new version of odoo for the new odoo.sh project. Activate the new project with our partner code in trial mode.

  2. Use the odoo upgrade bot [https://upgrade.odoo.com/database/upload] with the client Enterprise code and the latest backup (no need to upload the filestore). Choose testing and run extensive tests both locally and on the staging branch with the client.

  3. Once everything is working, plan a 2-3 hour downtime window with the client in which the migration will take place. Any modifications done during this window will not be carried over, if necessary a redirect to a WIP page can be set-up to ensure non logins/additions are made.

  4. Download the latest database backup and upload it to the upgrade bot, choose production as target version. Wait for the db to be generated (~30-40 min if all tests are correct), this step should run without issues if extensive testing has been done. While waiting for the database upgrade, create and download an archive of the filestore in the original project (i.e. tar -czvf filestore-<client>_$(date +%F).tar.gz ~/data/filestore/<database_name>)

  5. Rename the original project to old-<client> or any obvious name; rename the migration project to the original project name. This will preserve any DNS mappings that the client may have set-up but remember to add the DNS mapping in the settings section of the new project.

  6. Take note of the User Enterprise code in the original project, change the code of the original project to out partner code and the code to the migration project to the client code. This will deactivate the original project (which most likely will be dropped after some days) and activate the new project as the active one. Rud the cronjob update_notification (from the technical menu) to update the new UUID.

  7. Generate a new UUID, login as admin in debug mode in the original project and update the database.uuid in the technica-->system settings menu; this ensures that only the migrated project has the correct UUID and is considered valid.

  8. Restore the upgraded database in the new project using the backup --> import database page, if necessary, also copy the filestore tar to the new project and extract/copy all the files in the new filestore.

  9. All done, verify the new installation and notify the client of the upgrade.



Avatar
Abbandona