View source | Discuss this page | Page history | Printable version   


Migration to current appliances

Bulbgraph.png   This document refer to the appliance based on Ubuntu 20.04.

The migration guide for the old version 18.04 published in 2019 can be found here.



Bulbgraph.png   Always test the migration in testing servers, before doing the real migration.

A good idea is, if possible, to keep the old system around for a time. This way if something goes very wrong during or shortly after this migration it is possible to revert to the initial system.

Migrate to appliance 20.04

Currently, it is supported to migrate to the Appliance 20.04 from:

It is NOT possible to directly migrate from the following very old options:

Before the migration, it is highly recommended to have a running instance in a consistent state. This means that no local changes should be present in the database and that the application should compile without any issues.

This is recommended as it allows for clear and easy separation of any potential issue during the migration.

Check compatibility of Openbravo version

Openbravo recommends to use the latest Confirmed Stable (CS) release if possible.

Recommended version

To migrate to the new appliance 20.04 it is recommended to have at least the following Openbravo version (or higher):

This version has been fully tested in our CI system against the Appliance 20.04 stack.

Minimum version (extra testing needed)

The older version 19Q3 already includes the last code changes known to be required.

If you cannot upgrade to 20Q1 or higher 19Q3 should work however you should plan to do more extensive testing in that case.

Additional fix for some versions

Additionally versions between 20Q4 and 22Q4 (both included) should apply this fix as well: Issue 51718

Without it running install.source will fail with the error ERROR: DROP DATABASE cannot be executed within a pipeline

Read usage differences section for changes 18.04 to 20.04

Please read the entire Usage difference in Appliance 20.04 compared to 18.04 section.

It contain several important differences to be aware of.

attachment folder must exist

One side-effect of the new security configuration on restricting writing files is that tomcat cannot create the attachment folder itself if it should be missing.

The folder pointed to by the attach.path entry must be created before starting tomcat.

This folder is NOT just used by the attachment system but also for some other temporary files.

Check compatibility of modules used in your Installation

As the new Appliance 20.04 updates some stack components it maybe required to update modules to be compatible with it.

Any modules not created by you

In this case please ask the module owner to verify/test if the module is compatible.

Note: Any standard modules from Openbravo itself have been updated and should work with the new Appliance. Should you notice any problem please raise a support ticket/issue with Openbravo.

Modules created by you as a developer

This section is for developers to give some help on how to check compatibility for the new stack.

The main stack change comparing the older Appliance 18.04 with the new Appliance 20.04 is PostgreSQL 10 -> 12

Apart from module compiling and functionality testing the following gives some extra information on specific things to test:

The PostgreSQL project maintains a list of changes and known incompatibilities for each major release. Most of the time those are transparent to most modules. However to check in more detail please check:

Preparation checklist for migration

  1. Prepare new server, configure the timezone, install updates, reboot
  2. Check the tomcat and postgres config and migrate to the new server
    • /etc/profile.d/ # check if you have changed the xmx of tomcat, etc
    • /etc/postgresql/10/main/conf.d/91-local-custom.conf # Any custom changes done therein
    • Note: Ensure that the change is still needed, since maybe the new default value is equal or greater than old one.
  3. Check that you don't have any other databases different that the Openbravo standard one, the backup will ignore it and you need to copy manually in case that you still need it.
  4. Copy the needed keys of the /home/openbravo/.ssh/authorized_keys.
  5. Move the backups config
    • /etc/openbravo-backup.conf
    • crontab -l # as openbravo user will show the backups schedule
  6. Do a migration test to ensure that everything continues working in the new system
    • Do the functional test
    • Check all the logs for errors.
    • Check system log: run 'dmesg'. To ensure that there is no problems of out of memory. (More details in memory)
    • Check the memory of the system 'free -m' and check that you have swap. (More details in memory)
  7. When you do the final migration, remember that the first step is stop the production tomcat.

From Openbravo appliance 18.04

Attachments, check that you have the backups in the usual path, if not you need to manually copy to new instance, for appliance: /opt/OpenbravoERP/attachments

Appliance 20.04 has PostgreSQL 12 and in appliance 18.04 is PostgreSQL 10, the migration process will update the database, usually there are no problems in this migration but if you have custom developments, remember to check that they continue working.

Backup for migration from appliance 18.04:

If the new server is configured with public key, then you can follow this process.

Connect to the new server using a private key that is also valid for the old server:

ssh -A openbravo@<ip_new_server>

The '-A' option kind of exports the private key so allows to connect from the new serer to the old one using it. Care should be taken when using the '-A' option as to only use it when connecting to trusted servers.

Then copy the backup from there to the new server:

sudo mkdir -p /backups/manual     # create folder to store manual backups
sudo chown -R openbravo:openbravo /backups    # fix owner of backups folder recursively
scp openbravo@<ip_old_server>:/backups/manual/backup-xxx.tar /backups/manual/   # copy the backup from the old machine into the manual backups dir of the new instance.
# Note: Change backup-xxx.tar with the name of the backup just created.


Then you can connect by ssh to the new server and the backup will be in /backups/manual/ folder.

Bulbgraph.png   On restoring a backup created with PostgreSQL10 / Appliance 18.04 a single error message "ERROR: schema "public" already exists" will be shown on restore.

This specific error is harmless but not easily avoidable. It can be safely ignored.

From this point you can follow the normal restore process.

Things to do after the migration

After the migration, a good practice is take a look regularly to the system to check that everything continues fine:

Retrieved from ""

This page has been accessed 12,350 times. This page was last modified on 26 May 2023, at 09:28. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.