This documentation is for WSO2 Governance Registry 5.0.0. View documentation for the latest release.
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

To upgrade the version of WSO2 Governance Registry, the user store database should be upgraded. Note that there are no registry schema changes between versions. This topic provides instructions on how you can upgrade (the data and configurations) from WSO2 GREG 4.5.3 to WSO2 GREG 4.6.0. 

If you want to migrate your Governance Registry configurations from one instance to another (such as when promoting your instance from test to production) using the same Governance Registry release, see Migrating the Governance Registry.

Preparing to upgrade

The following are the specific prerequisites you must complete before you upgrade WSO2 GREG:

  • Before you upgrade to the latest version of WSO2 Governance Registry, you create a staging database, which is essentially an empty database. Note that you should NOT connect a new version of WSO2 GREG to an older database that has not been migrated.
  • Make backups of the database and the WSO2 product prior to upgrading the database. The backup can be taken by copying the home folder of the product.
  • Stop all the WSO2 products that are connected to the database.
  • If any files/folders are changing in the product pack to which you are upgrading, you need to make a backup of the relevant files/folders prior to changes.


The following are the limitations of upgrading.

  • This upgrading process can only be done for the same database types. For example, if you are using MySQL currently and you wish to use Oracle in the new version of GREG, these scripts will not work.
  • You cannot roll back the upgrading process. It is impossible to restore a backup of the previous server and retry the upgrading progress.


The downtime is limited to the time taken for switching databases when in the production environment.

Upgrading the database

  1. Stop the current Governance Registry 4.5.3 server.

    Before discarding the old GREG instance, make a backup of the GREG_HOME/solr directory. Solr-based index is required to re-index all the resources once migrated.

  2. Select the relevant script for the upgrade from here on the production database. The script you use will depend on the type of database you are using, for instance, if your database is MySQL you need to run the execute mysql-migration.sql command in MySQL (you would use Oracle or MSSQL to run the script if that is the database you are using). Running this script will ensure that the database is upgraded with the additional tables and schemas which are required for GREG 4.6.0.

    There are three migration scripts available: migration-service-provider.sqlmigration-identity.sql and migration.sql. However, for all Carbon products except WSO2 IS, only the migration.sql script is required to be executed.


  3. Once you run the migration script on the production database, copy the data from your production database to the staging database you created when preparing to upgrade. This becomes the new database for your new version of GREG.
  4. Download WSO2 Governance Registry 4.6.0 from
  5. To connect the new product version to the upgraded (staging) database, configure the following files: 
    1. Configure <PRODUCT_HOME>/repository/conf/datasources/master-datasources.xml. See here for more information on how to do this for your database.
    2. Go to the <PRODUCT _HOME>/repository/conf directory and update the datasource references in user-mgt.xml, registry.xml and api-manager.xml to match the updated configurations in the master-datasources.xml file which you made in the above step. The following are sample configurations if the datasource is jdbc/WSO2CarbonDB.

      <dbConfig name="wso2registry">
        <Property name="dataSource">jdbc/WSO2CarbonDB</Property>
  6. Replace the GREG_HOME/solr  directory with the backup you made in step 1. Note that this step is not a must but will make the re-indexing process faster.

Upgrading the configurations

  1. Open the <PRODUCT_HOME>/repository/conf/user-mgt.xml file and add the following property to the existing AuthorizationManager configuration as shown below.

    <Property name=“CaseSensitiveAuthorizationRules">true</Property>
  2. In the new product version, open <PRODUCT_HOME>/repository/conf/registry.xml and change the value of this indexing configuration as shown below.

  3. Perform any configurations required for the server, e.g., external user stores, clustering, caching, mounting.

    Note that configurations should not be copied directly between servers.

  4. Start the server.

Recommended checkpoints

The databases should contain the newly added tables, which are namely as follows:





Going into production

The following are recommended tests to run on the staging system. 

  • Create multiple user stores and try adding users to different user stores.

  • Create multiple tenants and add different user stores to the different tenants. Thereafter, add users to the various user stores. 

Once the above tests are run successfully, it is safe to consider that the upgrade is ready for production. However, it is advised to test any features that are being used in production.

  • No labels