¶ Odoo migrations manual
This document is under construction
We are also building a document regarding functional checks to do before migrations [Aspectes funcionals de la migració]
¶
¶ Previous analysis
- We check if OpenUpgrade scripts from the core modules are already migrated to the latest version, and if we cover all the functionality needed with them. To check so, there's the official documentation: https://oca.github.io/OpenUpgrade/index.html
- From the actual inventory, we check which OCA modules are available in the version we want to migrate. To check so, we've created this tool: https://git.coopdevs.org/coopdevs/tooling/oca-modules-migrator. Those modules that are no covered, will need to be migrated following the standard process to migrate OCA modules: https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-16.0
- We need to consider also those modules that are installed in the production instance which don't appear in our inventory, as they could generate issues in the future. We need to make sure the inventory is updated before starting the migration process. To check so, we run this query:
select write_uid from ir_module_module group by write_uid;¶ Previous functional requirements
- In Odoo v14, we always install the OCA Module “Account Reconciliation Widget”.
- Revisar si hi ha hagut modificacions de plantilles de correu. Podem agrupar plantilles per Creador>Darrera actualització. (a completar)
- We'll check for bank statements with the customer in Odoo v12, to validate them and/or moving them to processed in v14.
- We'll check for bank accounts without assigned partner.
¶ Migration environment
The migration process is shown in the following image:
To build this environment:
- In our project repository, we'll create a branch for each intermediate version and for the final version, leaving the actual branch as the main one. Those branches will be deleted after the migration, leaving only the last version one which will convert to the main one.
- For each one of those branches, we'll create some environment variables (XX is the Odoo version, ex. 12, 13. 14…):
- odoo_role_venv_name: "odoo-XX"
- odoo_role_odoo_path: "/opt/odoo_XX"
- odoo_role_odoo_config_path: "/etc/odoo_XX"
- odoo_role_odoo_modules_path: "/opt/odoo_modules_XX"
- Make sure you are using the last Odoo Provisioning Version tag
- Regarding the Python version used in each Odoo version, we use Python 3.7.13 until v14, Python 3.8.12 for Odoo v15 and Python 3.10.13 for Odoo v16.
- That will allow us to have different virtual environments (one for each Odoo version) in the same container. In each version (excepting the initial one where we'll provide the actual Odoo state), we'll provide:
- For versions equal or lower than Odoo v13, we'll provide an OpenUpgrade Odoo mirror: https://git.coopdevs.org/coopdevs/odoo/migrations/openupgrade-mirror/-/releases
- For versions equal or higher than Odoo v14, we'll provide a normal Odoo image, including the OpenUpgrade OCA modules.
- Always make sure to use the last version of openupgrade:
git+https://github.com/OCA/openupgradelib.git@master#egg=openupgradelib
odoo14-addon-openupgrade-framework==14.0.1.0.1.dev22
odoo14-addon-openupgrade-scripts==14.0.1.0.2.dev367
¶ Data migration process
When we've already build our environment, let's proceed with the data migration:
- We generate a production database backup. We deactivate mail and server crons in this process: https://handbook.coopdevs.org/ca/Sysadmin/Odoo/Deactivate-Mail-Servers-And-Cron-Jobs
- In our NextCloud, we create a pad where we'll write down all the modifications we do to fix our database, in order to replicate the process in the final migration.
- We execute sanity previous queries:
- Helpdesk mail templates
- Back accounts without assigned partner:
select acc_number, partner_id from res_partner_bank where partner_id is null;
- In case an Odoo v12 uses Cooperator (Easy-my-coop), we need to move from Easy-My-Coop modules to Cooperator inside Odoo v12. To do so, we run previously the script provided by Coop IT Easy. Afterwards, inside v12, we update the cooperator modules by executing the Odoo Instance with
--update cooperator --stop-after-init - We execute the migration scripts. To do so:
- For versions equal or lower than Odoo v13, we execute Odoo instance with
--update all --stop-after-init - For versions equal or higher than Odoo v14:
- Insert into /etc/odoo_xx/odoo.conf:
server_wide_modules=base,web,openupgrade_framework - We add the upgrade path into the Odoo instance execution:
--upgrade-path=/home/odoo/pyenv/versions/odoo-X/lib/python3.X/site-packages/odoo/addons/openupgrade_scripts/scripts --update all --stop-after-init
- Insert into /etc/odoo_xx/odoo.conf:
- We fix errors during the migration, iterating in the process and filling the pad with the executed queries
- When we succeed to finish a migration process to a new version, it's important to check the functional behavior, checking new and old dependencies:
- If the module is available in this new version, we install it inside the virtualenv, put in the inventory and repeat this process for the following versions.
- If the module is not available but will be in the following versions, we do nothing.
- If the module is deprecated or not available in this version and future versions, we uninstall it from the UI.
- Once we've finished the process, we clean up the database uninstalling the unused modules and regenerating assets from the UI.
- We set up a development instance to allow both the functional team and the customer to test and validate all the functionality before the final migration.
- It happens that in Odoo v16 you cannot backup a database from the UI. Instead, we use this tool to backup and afterwards we copy using SCP.
- For versions equal or lower than Odoo v13, we execute Odoo instance with
¶ Final migration setup
Once we've validated the functionality in our development instance and we've scheduled the final migration, we need to:
- Hire a new production server with the same performance than the actual one, updating the operating system.
- Redirect the production domain to this new machine or create a specific owned domain to provide this instance. Make sure at this point to define the steps to execute in order to avoid certificate, backups and monitoring duplicates or issues.
- Create a new Backups bucket for this machine.
- Provision the new machine enabling monitoring. We use the same backups credentials with a new bucket and restic password. If failban gives and error while provisioning:
sudo apt update¶ Final migration
We execute the following actions:
- Backup the production database. We deactivate crons and mails before executing the backup.
- Shutdown the production server instance
- Redirect DNS to the new server instance or ask the client to do so. Make sure not to generate a BackupExporter twice when providing certificates for the customer domain in the server.
- Repeat the migration process following the documentation we created in the development phase.
- Restore the migrated database into the new production instance, and check that functionality, backups and monitoring is working as expected. We reactivate crons and mails after this validation.
- If the URL domain has changed because of the migration, we modify the monitor-provisioning project in order to update SysAdmin Alerts.
¶ Following actions
Once we finish the migration:
- Disable the development and old production server instances, by deleting the server following this documentation: https://handbook.coopdevs.org/ca/Sysadmin/Infra/Create-Delete-Server
- We duplicate our production database to test, making sure this test database has mails deactivated: https://handbook.coopdevs.org/ca/Odoo/Sysadmin/How-To-Duplicate-A-Production-Db-And-Use-It-To-Test
- We merge the final version branch into master, with all the changes implemented (make sure odoo_xx environment variables are placed in local config.yml)