Migrate a live environment to upgrade the version

Service stopped: Migrate the data, install a new environment, test non-migrated elements behavior and compatibility with new bonita version

Overview

This page explains how to migrate your platform to a newer version of Bonita.

You can migrate your platform using the Bonita Migration Tool. There are 2 versions of the migration tool:

  • The version 1.x that migrate the platform from version 6.0.2 or later to any version up to 7.0.0

  • the version 2.x that migrate the platform from version 7.0.0 or later to any version up to the last one.

For example, if you are migrating from 6.5.3 to 7.1.0, you must migrate from 6.5.3 to 7.0.0 using version 1.x of the Bonita Migration Tool, and then migrate from 7.0.0 to 7.1.0 using version 2.x.

You should always migrate to the latest version of a major version. Usually, maintenance version might contain bug fixes made after the release of subsequent major or minor release.

For example, the 6.5.4 release contains fixes to certain bugs that were found in early 7.x.y versions, up to 7.1.0. When you are ready to migrate from 6.5.4 to a 7.x.y version, make sure you migrate to at least 7.1.1 to be sure that these fixes are present in your new version after migration. To migrate from 6.5.4 to 7.1.1 or later there are two phases: first you upgrade to 7.0.0 then to the latest version. You are recommended not to start 7.0.0 after you migrate to it, but to proceed immediately with the second phase of the migration.

JRE requirements:

  • Versions 7.0 to 7.4 only support JRE version 7. If you comes from older versions of Bonita supporting JRE 6, you must also upgrade your JRE to version 7.

  • Version 7.5 only supports JRE version 8. If migrating to version 7.5, please upgrade your JRE to version 8.

  • For more info, see Support Guide and Supported Environment Matrix for Server.

RDBMS requirements: The version targeted may not support the version of the database that is being migrated. You may then need to upgrade the version of your database prior to running the migration tool.

Community/Subscription edition: The tool migrates your platform (bonita_home folder and the database). You cannot change edition while migrating.

  • If you are running a Bonita Subscription Pack edition, you need a valid license for your target version.

  • If you are upgrading to a new maintenance version and not changing the minor version number (for example, you are migrating from x.y.0 to x.y.1), your current license remains valid after migration.

Starting from version 7.3 there is no more bonita home folder. This means that, if your installation does not have any custom change, then you do not need to configure the bundle any further for an installation migrated in 7.3 or above.

On the other hand, if you have customized your configuration, you will have to use the platform setup tool to send your customized configuration files to the database where configuration is stored, for versions 7.3 and above.

Migration steps

How it works

The Bonita Migration Tool contains a set of script that execute changes on the data to make it compatible with earlier version of Bonita Platform. This tool is provided as a zip archive and contains an executable script that will determine your current configuration and ask you in which version you want to migrate.

The migration is step-wise by maintenance version and the script manages the sequence of steps from your current version to the target version. After each minor or maintenance version upgrade, you have the option to pause or continue to the next step.

The migration script migrates the following:

  • Engine server

  • Engine database, including all data on active and archived process instances

  • Organization definition

  • Runtime data in Bonita Home, until 7.3

  • Configuration files in Bonita Home, which are replaced with the default configuration files for the new version

  • Log files from the previous version are not impacted by migration

The following are not migrated automatically:

  • Configuration of the platform: Before 7.3 in the Bonita Home folder and after 7.3 in database. Reapply your customizations manually after the migration script has finished (using platform setup tool if migrated to 7.3.0+).

  • Deployed process definitions: The processes will continue to run using the definition created in the previous version of Bonita.

  • Process definition sources (.bos files): Migrate these by importing them into the new version of Bonita Studio.

  • Business data model, and the business data database: if the migration path include version 7.0.0,7.2.0 or 7.2.4, the Business data model must be redeployed after migration. You can pause the tenant before migration, as a tenant admin, so that you’ll be able to redeploy the BDM on a paused tenant once migration is done, using Define and deploy the BDM). Otherwise, no action is required.

  • Custom connectors, actor filers, data types: These might continue to work in the new version, but should be tested, depending on your custom code.

  • Custom pages: These might continue to work in the new version, but should be tested depending on your custom code.

  • Custom reports: These might continue to work in the new version, but should be tested depending on your custom code.

  • REST API Extensions: These might continue to work in the new version, but should be tested depending on your custom code.

When the script has finished, you need to complete the migration by unzipping and configuring a bundle for the new version. See Migrate your platform for step-by-step instructions.

Constraints

  • If you have added custom indexes to certain tables in the Engine database, you must remove them before migrating to a later version. If you do not remove these indexes, the migration will not complete.

  • There is no guarantee that the Look & Feel definition is compatible across maintenance versions. For example, in 6.2.2, jquery+ was renamed jqueryplus in BonitaConsole.html, for compatibility with more application servers. If you are using a custom Look & Feel, export it before migrating. Then after the migration is complete, export the default Look & Feel from the new version, modify your custom Look & Feel to be compatible with the new definition, and with the recommendations for form footers. Then import your updated custom Look & Feel into Bonita Portal.

  • The migration script supports MySQL, Postgres, Oracle, and Microsoft SQL Server. There is no migration for h2 database.

Important:
The migration operation resets the Bonita configuration files to default version for new settings to be applied (from the $BONITA_HOME folder in <7.3.0 version or inside database in >=7.3.0). Therefore, you must do a backup of your configuration files before starting the migration.
You will need to merge custom properties and configurations to the migrated environment.

Furthermore, from the database point of view, as any operations on a production system, a migration is not a zero risk operation.
Therefore, it is strongly recommended to do a backup of your database before starting the migration.

Estimate time required

The platform must be shut down during migration. The time required depends on several factors including the database volume, the number of versions between the source version and the target version, and the system configuration, so it is not possible to be precise about the time that will be required. However, the following example can be used as a guide:

Database entries:

data: 22541
flownode: 22482
process: 7493
connector: 7486
document: 7476

Source version:

6.0.2

Target version:

6.3.0

Time required:

2.5 minutes

Migrate your platform

This section explains how to migrate a platform that uses one of the Bonita bundles.

  1. Download the target version bundle and the migration tool for your Edition from the Bonitasoft site for Bonita Community edition or from the Customer Service Center for Bonita Subscription Pack editions.

  2. Check your current RDBMS version is compliant with the versions supported by the target version of Bonita (see above)

  3. Unzip the migration tool zip file into a directory. In the steps below, this directory is called bonita-migration.

  4. If you use Oracle, there is already the driver for 19.3.0.0 oracle version in the bonita-migration/lib. add the JDBC driver for your database to bonita-migration/lib. This is the same driver as you have installed in your web server lib directory. You must upgrade to Oracle 12c (12.2.x.y) in order to migrate to 7.9+.

make sure you double check that you use the official driver version that match your Database version. The correct driver is mandatory for a smooth migration: Follow instructions for Oracle driver download. Particularly, if you use Oracle 12.2.0.x.y and are migrating to 7.9.n or to 7.10.n, then remove the existing ojdbc8-19.3.0.0.jar file, and add the specific JDBC driver to bonita-migration/lib.
  1. If you use Microsoft SQL Server, add the JDBC driver for your database type to bonita-migration/lib. This is the same driver as you have installed in your web server lib directory.

  2. Configure the database properties needed by the migration script, by editing bonita-migration/Config.properties. Specify the following information:

    Property Description Example

    bonita.home

    The location of the existing bonita_home. Required only until 7.3

    /opt/BPMN/bonita (Linux) or C:\\BPMN\\bonita (Windows)

    db.vendor

    The database vendor

    postgres

    db.driverClass

    The driver used to access the database

    org.postgresql.Driver

    db.url

    The location of the Bonita Engine database

    jdbc:postgresql://localhost:5432/bonita_migration

    db.user

    The username used to authenticate to the database

    bonita

    db.password

    The password used to authenticate to the database

    bpm

Note: If you are using MySQL, add ?allowMultiQueries=true to the URL. For example, db.url=jdbc:mysql://localhost:3306/bonita_migration?allowMultiQueries=true.
Also, if you are migrating to Bonita 7.9+, you must upgrade your database server to MySQL 8.0, see Migrating to Bonita 7.9+ using MySQL specific procedure below.

  1. If you use a custom Look & Feel, export it, and then restore the default Look & Feel.

  2. Generally speaking, pausing (or not) the BPM services before migrating should not impact migration. There are however a few special cases:

    • If you are migrating from a version < 7.3.0. If you are using a BDM, your BDM will have to be redeployed after migration (see above). In this case, it is recommended you stop your BPM services before migrating, so as to be able to redeploy your BDM immediately after migration (and not having to deal with eventual errors in automated processes as you restart your platform after migration).

    • Several bugs affect legacy versions of Bonita that prevent a smooth migration of a Bonita platform with BPM services paused in special cases:

      • Starting version is before 7.8.0, and your target version is between 7.8.0 and 7.11.5

      • Starting version is before 7.10.5 & target version is before 2021.1

    • Therefore, while it is recommended to always migrate to the latest version of Bonita, if your target version is not 2021.1, or above, it is necessary to migrate with BPM services running.

  3. Stop the application server.

  4. IMPORTANT: Back up your platform and database in case of problems during migration.

  5. Go to the directory containing the migration tool.

  6. Run the migration script:

    • For version 1.x of the migration tool, run migration.sh (or migration.bat for Windows).

    • For version 2.x of the migration tool, go to the bin directory and run the migration script for your edition and operating system:

      Community edition

      bonita-migration-distrib (Linux) or bonita-migration-distrib.bat (Windows)

      Subscription editions

      bonita-migration-distrib-sp (Linux) or bonita-migration-distrib-sp.bat (Windows)

    • Starting from version 2.44.1, an additional script called check-migration-dryrun is present in the same folder. This script only run checks the migration would without actually migrating. This is equivalent to running the migration script with a --verify option.

  7. The script detects the current version of Bonita, and displays a list of the versions that you can migrate to. Specify the version you require. The script starts the migration.

  8. As the script runs, it displays messages indicating progress. After each migration step, you are asked to confirm whether to proceed to the next step. You can pause the migration by answering no. To suppress the confirmation questions, so that the migration can run unattended, set the ` (-Dauto.accept=true)` system property. When the migration script is finished, a message is displayed showing the new platform version, and the time taken for the migration. The database have been migrated.

Do not use the old application server: a new one needs to be installed with the Bonita binaries that match the target version.
  1. Unzip the target bundle version into a directory. In the steps below, this directory is called bonita-target-version.

  2. Configure the bundle to use the migrated database.

    Do not recreate the database and use the setup tool of the bonita-target-version Edit the bonita-target-version/setup/database.properties file to point to the migrated database.

  3. Reapply configuration made to the platform, using the setup tool of the bonita-target-version

    Download the configuration from database to the local disk.

    There is below a Linux example:

     cd setup
     ./setup.sh pull

    You must reapply the configuration that had been done on the original instance’s BONITA_HOME into the bonita-target-version/setup/platform_conf/current ``

    Please refer to the guide on updating the configuration file using the platform setup tool

    When done, push the updated configuration into the database:

     ./setup.sh push
  4. If you have done specific configuration and customization in your server original version, re-do it by configuring the application server at bonita-target-version/server (or bonita-target-version if target version is 7.3.n): customization, libs etc.

  5. If your Bonita version is 7.4 or above before migrating, you can skip this point. In the case where deployed resources have required dedicated authorizations to use the REST API, these authorizations are not automatically migrated. Some manual operations have to be done on files that are located in the extracted platform_conf/current folder (see Update Bonita Platform configuration for more information). You need to:

    • Perform a diff between the version before migration and the version after migration of tenants/[TENANT_ID]/conf/compound-permissions-mapping.properties and put the additional lines into the file tenants/[TENANT_ID]/conf/compound-permissions-mapping-custom.properties

    • Perform a diff between the version before migration and the version after migration of tenants/[TENANT_ID]/conf/resources-permissions-mapping.properties and put the additional lines into the file tenants/[TENANT_ID]/conf/resources-permissions-mapping-custom.properties

    • Perform a diff between the version before migration and the version after migration of tenants/[TENANT_ID]/conf/dynamic-permissions-checks.properties and put the additional lines into the file tenants/[TENANT_ID]/conf/dynamic-permissions-checks-custom.properties

    • Report all the content of the version before migration oftenants/[TENANT_ID]/conf/custom-permissions-mapping.properties into the new version.

  6. Configure License:

    you need to put a new license in the database: see Platform configuration for further details. There is below a Linux example:

     cd setup
     vi database.properties
     ./setup.sh pull
     ls -l ./platform_conf/licenses/

    If there is no valid license in the ./platform_conf/licenses/, these 2 pages will help you to request and install a new one:

    Install the new license:

    +

     cp BonitaSubscription-7.n-Jerome-myHosname-20171023-20180122.lic ./platform_conf/licenses/
     ./setup.sh push
  7. Start the application server. Before you start Bonita Portal, clear your browser cache. If you do not clear the cache, you might see old, cached versions of Portal pages instead of the new version. Log in to the Portal and verify that the migration has completed. If you did not set the default Look & Feel before migration and you cannot log in, you need to restore the default Look & Feel using a REST client or the Engine API.

  8. If you migrated pasted version 7.7 In that case, if you used the migration tool 2.41.1 or greater, the table arch_contract_data is automatically backed up to the table arch_contract_data_backup to avoid long lasting migration. To reintegrate the data into your installation, a new tool is provided in versions 2.46.0 and above. It is located in the tools/live-migration folder. Follow instruction in the README.md to run this tool and re-integrate data from arch_contract_data_backup.

The migration is now complete. If you were using a custom Look & Feel before migration, test it on the new version before applying it to your migrated platform.

Migration of processes with 6.x forms and case overview pages

Until the version 7.0.0, Bonita used UI artifacts based on the Google Web Toolkit (GWT) technology: process instantiation, task execution forms and case overview page. The runtime support for those forms and pages was removed in 7.8.0.

It means that if one or more processes on the migrated server uses 6.x forms or overview page, the migration to a version above 7.7.x cannot be performed directly. The following lines explain how to migrate to a version 7.8.0.

Specifically if you are migrating from a 6.x version:

  • Migrate to the 7.0.0 using the migration tool 1.x.

  • Migrate to the last 7.7.x version, using the migration tool 2.x.

  • Redesign your process to use contracts at process instantiation and task execution levels, and recreate all your forms and case overview pages in the Studio using the UI Designer or your favorite IDE, so that they use contracts. For more information, go to migrate a form from 6.x

  • Upload the new version of all your processes using contracts, new forms, and new case overview pages.

  • Make sure the versions of the processes using 6.x forms have no more running instances, and disable them.

  • Perform the migration to the desired version.

If you are migrating from a 7.x version:

  • Redesign all your forms in the Studio using the UI designer. See here for more info.

  • Upload the new version of all your processes using the new forms.

  • Disable the version of your processes using 6.x forms. Make sure they have no more running instances.

  • Perform the migration to the desired version.

The disabled processes with 6.x forms will not be able to be enabled again post migration. Having 6.x case overview pages on your processes will not prevent the migration of the platform, however they will all be replaced by the default 7.x case overview page, created with the UI Designer. It means that you might want to redo the case overview page as well as the forms, especially if you have configure a custom case overview page for your processes in version 6.x. Or (for Enterprise, Performance, and Efficiency editions only), you can live update it after migration.

Note: 6.x application resources have been removed too in 7.8.0, so if you are migrating a process that leverage this feature, you need to modify it (for example to use process dependencies instead (Configure > Process dependencies in Bonita Studio)).

Use the provided Bonita tool to update case overview pages before migrating to 7.8.0

Bonita Migration Tool now ships an option to allow you to replace 6.x case overview pages with the default 7.x case overview page (created with the UI Designer), when your Bonita runtime is still in a pre-7.8.0 version. This allows you to see if the page suits your needs, or if not, it can be used as a base to customize your case overview page. Your pages will then be ready for the 7.8.0 migration step.

To run it, unzip the latest Migration Tool and run, for Community edition:
./bonita-migration-distrib (Linux) or bonita-migration-distrib.bat (Windows) --updateCaseOverview <PROCESS_DEFINITION_ID>

or for Subscription edition:
./bonita-migration-distrib-sp (Linux) or bonita-migration-distrib-sp.bat (Windows) --updateCaseOverview <PROCESS_DEFINITION_ID>

For instance:

./bonita-migration-distrib-sp --updateCaseOverview 6437638294854549375

If you want to update several processes, simply run the command with all the processDefinitionId’s one by one.

Note: This tool will only change case overview pages. This means that if some of your processes still have process instantiation / task execution forms, you need to redesign them in the Studio using Bonita UI designer, as explained in the section above.

Example of output issued when running the tool:

Migrating to Java 11 in Bonita 7.9

Bonita 7.9+ supports Java 11. Migrating an existing platform to Java 11 is not an easy, or painless endeavour. To migrate a Bonita platform to Java 11, you need to follow the following steps:

  • Migrate the platform to Bonita 7.9.0 as usual, and keep running it in Java 8. Verify that everything works as expected.

  • Test the migrated platform in Java 11, on a test environment.

  • Once tested, update what is required on the production server, and switch it to Java 11.

The main parts that require attention and testing are connectors and custom code. While the 7.9.0 migration step tries its best to migrate the implementation of connectors that are known not to work in Java 11, namely WebService, CMIS, Email and Twitter, custom connectors, groovy scripts, rest api extensions etc. are not migrated and might not work outright in Java 11. Aside from just code incompatibility, special attention has to be given to the dependencies of the custom code, as they might either not work in Java 11, work fine but conflict with Bonita own dependencies or the script might use dependencies previously included in Bonita, but no more accessible, or accessible in a different version.

Migrating to Bonita 7.9+ using PostgreSQL

Bonita 7.9+ supports PostgreSQL 11.x (x>=2) which is not compatible with previous versions. When migrating to Bonita 7.9+ using PostgreSQL follow this procedure:

  • shutdown Bonita

  • Run Bonita migration tool to the latest Bonita version supporting postgres 9 (7.8.4)

  • Backup the Bonita database

  • Migrate PostgreSQL from 9 to 11.x (x>=2) following the [Official documentation] (https://www.postgresql.org/docs/11/upgrading.html)

  • Run again the migration tool to the desired Bonita version requiring PostgreSQL 11

  • Restart your updated Bonita platform

Migrating to Bonita 7.9+ using MySQL

Bonita 7.9+ supports MySQL 8.0.x version, which is not compatible with older versions of MySQL. For this reason, to migrate to Bonita 7.9+ when using MySQL, please follow this procedure:

  • ensure your Bonita platform is shut down

  • run Bonita migration tool to update Bonita platform to version 7.9 or newer, following the procedure above

  • upgrade your MySQL database server installation following the official documentation

  • once done, you can restart your updated Bonita platform

Migrating to Bonita 7.9+ using Oracle

Bonita 7.9+ supports Oracle 12c (12.2.0.x.y) and Oracle 19c (19.3.0.0) versions: this is a requirement change.

The Oracle database server change needs to be done before using the Bonita migration tool from 7.8.4 to 7.9.0.

Migrate to 7.8.4

Skip this section and jump directly to Upgrade Oracle database server section if the 7.8.4 is already the version in use.

  • shut down the Bonita platform

  • run Bonita migration tool to update Bonita platform to version 7.8.4, following the migration procedure above

Upgrade Oracle database server

  • shut down the Bonita platform

  • upgrade the Oracle database server to the version 12c (it must be 12.2.0.x.y) or 19c (it must be 19.3.0.0)

Configure the Oracle database server

  • configure the Oracle database server, in particular activate the XA transactions management: see the Oracle Database section in the Database creation and configuration for Bonita engine and BDM page

  • install the missing Oracle components

  • execute the SQL scripts to install XA management elements

  • execute the SQL requests to GRANT the proper rights to the Oracle users; for both Bonita BPM and BDM schemas

Download the specific jdbc driver for the Oracle 12c (12.2.0.x.y) or 19c (19.3.0.0)

Beware: two different jdbc driver jar files may share the same name (ojdbc8.jar).

Each file however is specific to the Oracle DB server version installed. Please make sure to download the appropriate one:

Note I: The migration tool already includes the oracle driver for Oracle 19c (19.3.0.0) in the bonita-migration/lib directory. If your are not using Oracle 19c (19.3.0.0) you need to replace it.

Check the Bonita 7.8.4 server starts with the Oracle database server 12c (12.2.0.x.y) or 19c (19.3.0.0)

  • download and install a Bonita 7.8.4 server

  • setup the Bonita 7.8.4 server to use the Oracle 12c (12.2.0.x.y) or 19c (19.3.0.0) database

  • request and install a temporary 7.8 license in the Bonita server

  • start the Bonita 7.8.4 server

  • check you can successfully log into the portal

Migrate to 7.9+

  • shut down the Bonita platform

  • run the migration tool to migrate the platform to 7.9+, following the migration procedure above

  • then upgrade your Oracle database server to the version 12c (it must be 12.2.x.y)

  • in a second step, run the migration tool again to migrate the platform to 7.9.0 or newer

  • once done, you can restart your updated Bonita platform

Migrating to Bonita 7.11+ using Oracle

Bonita 7.11+ supports Oracle 19c version. To migrate to Bonita 7.11+ when using Oracle, please follow this procedure:

  • ensure your Bonita platform is shut down

  • in a first step, run Bonita migration tool to update Bonita platform to version 7.10.5, following the procedure above

  • then upgrade your Oracle database server to version 19c (version 7.10.x is compatible with 12c and 19c.)

  • in a second step, run the migration tool again to migrate the platform to 7.11.0 or newer

  • once done, you can restart your updated Bonita platform

NB : When upgrading the Oracle database ensure that the initialisation parameter Compatible is not set to a previous version. You can check this with the query:

SQL> SELECT name, value FROM v$parameter
         WHERE name = 'compatible';

Migrate between maintenance versions of Bonita in Bonita 7.11+

Starting with Bonita 7.11+, upgrading between maintenance versions of Bonita does not require the migration tool. To upgrade between maintenance versions in bonita 7.11+ (for example going from 7.11.0 to 7.11.1) follow the following steps:

  • Download the new bundle version from Bonitasoft site for Bonita Community edition or from the Customer Service Center for Bonita Subscription editions.

  • Shut down your old Bonita Runtime.

  • Unzip and configure the new bundle. This means copying the configuration files of the old Bonita Runtime, mainly database.properties, server.xml, internal.properties if changes have been made in them.

  • Start the new bundle

  • Delete the old bundle files

NB : In a cluster environment, you need to stop all your nodes, update them, before starting them with the new maintenance version.

Migrate your cluster

A Bonita cluster must have the same binary version of Bonita and database version on all nodes.

To migrate a cluster:

  1. Download the migration tool:

    • In version 1.x you need to download the tool for Performance cluster, the ordinary Performance migration tool does not support migration of a cluster.

    • In version 2.x there is only one kind of migration tool. It will work for both cluster and non cluster installation.

  2. Shutdown all cluster nodes.

  3. On one node, follow the procedure above to migrate the platform.

  4. When the migration is complete on one node, follow steps 12 to 16 on all the other nodes.

The migration of the cluster is now complete, and the cluster can be restarted.

Migrate your client applications

If you have applications that are client of Bonita, you may have to change your client code or library. Most of the time, we guarantee backward compatibility. In any cases, please read the release notes to check if some changes have been introduced.

In addition, if your application connects to the Bonita Engine using the HTTP access mode, see the bonita-client library documentation page.

Migration troubleshooting

Timers are stuck after migrating to 7.10.0+

Symptom: When migrating to 7.10.0+ the timers on processes don’t work anymore.

Cause: Bug in the pause/resume of tenant services, fixed in 7.12.1 version. This issue happens because the BPM services were paused before the migration was performed.

Solution: If the BPM services were paused before migrating or had to be paused for whatever reason, then to resolve this, you need to execute the following database requests after the migration completes, and before you restart your Bonita platform:

DELETE FROM QRTZ_PAUSED_TRIGGER_GRPS;
UPDATE QRTZ_TRIGGERS SET TRIGGER_STATE = 'WAITING' WHERE TRIGGER_STATE = 'PAUSED';

After this operation, the table QRTZ_PAUSED_TRIGGER_GRPS should be empty, and all the triggers in the QRTZ_TRIGGERS table should be in state waiting, and not paused.

Some foreign keys are duplicated

This issue is fixed in Bonita 7.11.6, without any action required from the user.

Symptom: After migrating to a Bonita version between 7.11.0 and 7.11.5, after re-installing/updating the BDM, some foreign key constraints are effectively duplicated: there are foreign keys that refer to the same columns and tables, but with a different name.

Cause: A bug was introduced in Bonita 7.11.0 by upgrading an external library, Hibernate from version 4 to 5. This new version introduces a known bug.

Solution: Doing nothing is an option, as there is no change in product behaviour. If you wish to clean your BDM database, follow the procedure below:

  1. Stop your bonita server

  2. Open the db in an edition tool (or execute in command line the relevant commands):

First, select all the foreign keys on a table of your BDM objects:

MySQL

SELECT
TABLE_NAME,COLUMN_NAME,CONSTRAINT_NAME, REFERENCED_TABLE_NAME,REFERENCED_COLUMN_NAME
FROM
INFORMATION_SCHEMA.KEY_COLUMN_USAGE
WHERE
REFERENCED_TABLE_SCHEMA = '<your_business_data_db_name>' AND
REFERENCED_TABLE_NAME = '<your_table_name>';

MS SQL Server

select
name [foreign key constraint name],
OBJECT_NAME(parent_object_id) [created table],
OBJECT_NAME(referenced_object_id) [referenced table]
from sys.foreign_keys
where
parent_object_id = OBJECT_ID('<your_table_name>') OR
referenced_object_id = OBJECT_ID('<your_table_name>')

PostgreSQL

SELECT conname,
pg_catalog.pg_get_constraintdef(r.oid, true) as condef
FROM pg_catalog.pg_constraint r
WHERE r.conrelid = '<your_table_name>'::regclass AND r.contype = 'f' ORDER BY 1
  1. These requests will give you all the foreign keys on a table. Among these, search for duplicated ones: the duplicated foreign keys should have the following names: FK_<hash> & FK<another_hash>. The two different names should be for keys referencing the same columns on the same table. Delete the one named: FK_<hash>.

  2. Repeat for all the tables of your BDM database.

  3. Start your bonita server

Guidance is not provided for Oracle, as the situation is impossible. Oracle prevents the creation of 2 identical foreign keys with different names.
Instead, the BDM redeployment will fail after migration. Migrating to Bonita 7.11.6 or higher fixes the issue.