This site contains the documentation that is relevant to older WSO2 product versions and offerings.
For the latest WSO2 documentation, visit https://wso2.com/documentation/.

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

« Previous Version 3 Next »

This guide takes you through the steps for migrating few of the most used products from their older version to newer versions. E.g., Product versions based on Carbon 4.0.0 to newer versions based on Carbon 4.1.0 or 4.2.0. For more information on release versions, see the Release Matrix.

Preparing to Upgrade

 Before starting the migration, the following prerequisites must be followed on the database.

  • A separate staging database should run as the production database server. As a result, once the migration process is completed, the database server should have the configurations required for a production server.
  • Take backups of the database and system prior to migrating the database. The system backup can be taken by copying the Carbon server home folder.
  • Shut down all the Carbon servers connected to the database before running the migration scripts.
  • Since a separate database (staging database) is used for the migration instead of the actual production database, the data that is collected in the actual production system while the migration is in progress should later be added to the migrated database using a script. 
  • The database administrator should collect the data portion that is added to the production database, while the migration is in progress. Generally, the WSO2 support team will provide help in these types of situations.

  • If any files/folders are changing in the product pack to which you are migrating, you need to make a backup of the relevant files/folders prior to changes.

    New product (e.g. IS 4.5.0) must not be connected to the old database (e.g. IS 4.0.0) without executing the migration script provided in the old database.

Limitations

Following are the limitations of data migration:

  • This migration can only be done for some database types. For example, if you are using MySQL currently and you need to migrate to Oracle in the new version, these scripts will not work.
  • You cannot rollback migration. It is impossible to restore a backup of the previous server and retry the migration progress.

Downtime

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

Upgrade Procedure

Follow the instructions below to upgrade the system:

  1.  Stop the current server.
  2. Select the relevant script for the upgrade from here. Select the migration.sql script corresponding to your database type. E.g., If your database is MySQL, you need to execute mysql-migration.sql.Note that there are three migration scripts available: migration-service-provider.sql, migration-identity.sql and migration.sql. However, for all Carbon products except WSO2 IS, only the migration.sql script is required to be executed.
  3. To connect the new product version to the migrated database, configure the following files: 
    -Configure <PRODUCT_HOME>/repository/conf/datasources/master-datasources.xml. 
    -Go to the <PRODUCT_HOME>/repository/conf directory and update datasource references in user-mgt.xml and registry.xml. 

    To migrate configurations:
  4. Copy the <ESB_HOME>/repository/deployment/server/synapse-configs/default folder from the older ESB version to the new version.

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

    Note that configurations should not be copied directly between servers.

  6. Start the server.

Recommended checkpoints

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

  • UM_DOMAIN

  • UM_SYSTEM_USER

  • UM_SYSTEM_ROLE

  • UM_SYSTEM_USER_ROLE

Going into production - Recommended tests

The following are the 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.
  • The staging database should be used as the new production database with the new Carbon server. The staging server should have the configurations equivalent to the production server. Map the production domain to the staging environment, once the staging environment is running smoothly. This upgrade should be done during a period when there is low traffic on the system.

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

  • No labels