Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.

The following steps describe how to upgrade WSO2 Application Server from version 5.2.1 to 5.3.0. To upgrade from a version older than 5.2.1, start from the documentation that was released immediately after your current release and upgrade incrementally. For more information on release versions, see the Release Matrix


The instructions on this page takes you through the steps for upgrading from AS 5.2.1 .0 to AS 5.23.10. This includes upgrading the database changes as well as the configurations that should follow the upgrade.


The following prerequisites must be completed before upgrading:

  • Take Make a backup of the user and registry databases of AS 5.2.1

  • Take Make a backup of <AS_HOME_5.2.1> folder to backup the product configurations. 

  • Download WSO2 Application Server 5.3.0 from


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

Upgrading the database/registry

There are no registry and user database schema changes between AS 5.2.1 and 5.3.0. Therefore, you do not need to do any database schema migration. However, you should create a backup of the existing database, and create a duplicate database to use with a newer product version. This is described below.


You should NOT connect a new version of WSO2 AS to an older database that has not been upgraded.


Migrating the configurations

Before you start updating the configuration files in The following topics explain the configuration changes that need to be updated for AS 5.3.0, create a new database and restore the backup of the old database in this new database.:

Table of Contents

Updating the configuration files


  1. Create a new database for AS 5.3.0 and restore the backup of the old database in this new database.
  2. To connect AS 5.3.0 to the upgraded database, configure the following files:
    1. Configure the <AS_HOME_5.23.1>0>/repository/conf/datasources/master­datasources.xml file as shown in the following example:

      Code Block
      user manager</description>
      <description>The datasource used for registry and
      <definition type="RDBMS">
    2. Go to the <AS _HOME_5.23.1>0>/repository/conf/ directory and update the datasource references in the user-­mgt.xml and registry.xml files to match the updated configurations in the master­datasources.xml file. The following are sample configurations if the datasource is “jdbc/WSO2CarbonDB”:


      Code Block
      <dbConfig name="wso2registry">


      Code Block
  3. The SaaS application configuration in webapps has been changed. So, if you are using SaaS features, you need to update your web applications. Previously, users have configured the SaaS configuration via web.xml Data services feature is no longer shipped with WSO2 Application Server. If you need to use the data services hosting feature, you have two options:
    1. Install the Data Services hosting feature from the public p2-repo. See Installing Features for instructions.

    2. Use the WSO2 Data Services Server product which can be downloaded from See the About this Release page to check if the latest WSO2 DSS is compatible with the current AS version.

  4. The configurations for SaaS web applications has changed in AS 5.3.0. In previous releases, SaaS configurations were enabled in the web.xml file of the web application by adding a context-param called carbon.enable.saasIn the new versionAS 5.3.0, SaaS is configured via the context.xml configuration file  file that needs to be placed under the META-INF/ folder of the webappweb application. See the following documentation for more details - configuration in AS 5.2.1 has been converged into the carbon.xml. But users wanted to configure different keystore for SSL communication, and so on. Hence, in more details about configuring SaaS applications in AS 5.3.0 from here.
  5. Prior to AS 5.3.0, the primary keystore configured in the carbon.xml file was used for securing transports. In AS 5.3.0,


    the keystore used for transports should be separately


    configured in the

    transport keystores through

    catalina-server.xml file.


    The “RegistryKeyStore” configuration


    in carbon.xml

    has been

     is removed.

    This is not really there in the AS 5.2.1, but was added later in a patch. This has been reverted in AS 5.3.0

     See the section on configuring keystores for more information.

  6. Check for any other configurations that were done for AS 5.2.1 .0 (based on your solutions), and update the configuration files in AS 5.23.1 0 accordingly. For example, external user stores, caching, mounting, etc.

Migrating third party libraries

If there are any third party libraries used with AS 5.2.1 that you want to migrate, copy them to the  following following directories as applicable to in AS 5.3.0 as applicable.

  1.  If you have used JDBC drivers etc, copy them into to the <AS_HOME>/repository/components/lib directory.
  2. If you have used OSGi bundles such as SVNKit etc, copy them into to the <AS_HOME>/repository/components/dropins directory.   

Migrating the services and artifacts

You can migrate all artifacts relevant to the super - tenant and as well as the ordinary tenants by copying the following directories from the old server to the new server.

  1. To migrate the super - tenant’s artifacts, copy the <AS_HOME>/repository/deployment/server/ directory from AS 5.2.1 to AS 5.3.0.

  2. If you are using multi­-tenancymulti­tenancy, copy the <AS_HOME>/repository/tenants/ directory  directory from AS 5.2.1 to AS 5.3.0.

  3. Since the Axis2 Quality of Services UI to apply policies such security has been removed from the management console, users need to use alternative mechanisms and apply the policies for their services. For Axis2 AAR services, the policies can be applied through the services.xml. Refer <link to page on how to apply QoS configuration if any> for more details. To globally engage modules, users need to use axis2.xml that can be found at AS_HOME.

  4.  In AS 5.3.0, it is not possible to globally engage modules using the management console. Therefore, you need to update the axis2.xml file in the <AS_HOME>/repository/conf/axis2 directory . Refer the following sample:as shown below. You can find more information on engaging modules for axis2 services from here.

    Code Block
    <axisconfig name="AxisJava2.0">
        <module ref=”addressing”/>

    The UI to globally engage a module is no longer available.

Migrating the tenant settings and applications

You can migrate all artifacts etc. relevant to tenants by copying the following directories from the old server to the new server.

  1. To migrate the deployment artifacts, copy the <AS_HOME>/repository/deployment/server/ directory from AS 5.1.0 to AS 5.2.1.
  2. If multi­tenancy is used, copy the <AS_HOME>/repository/tenants/ directory from AS 5.1.0 to AS 5.2.1.
  3. If axis based services are included in the directories that were copied above, you must do the following:
    1. Open the metadata files corresponding to the axis services from the following locations:
      1. The metadata files of axis services for the super tenant are stored in the <AS_HOME_5.2.1>/repository/deployment/server/servicemetafiles/ folder.
      2. The metadata files of axis services for each tenant can be found in the <AS_HOME_5.2.1>/repository/tenants/<Tenant_No>/servicemetafiles/ folder.
    2. When you open each metadata file, remove all occurrences of the following:

      Code Block
      <module name="activation" version="2.1.0" type="engagedModules"/
  4. If any JAXRS and JAXWS applications were copied from the old server (in step 1 and step 2), they must be moved as follows:
    1. For the super tenant, these applications should be moved from the <AS_HOME_5.2.1>/repository/deployment/server/jaxwebapps/ folder to the <AS_HOME_5.2.1>/repository/deployment/server/webapps/ folder.
    2. For other tenants, these applications should be moved from the <AS_HOME_5.2.1>/repository/tenants/<Tenant_No>/jaxwebapps/ folder to the <AS_HOME_5.2.1>/repository/tenants/<Tenant_No>/webapp/ folder.
  5. Start WSO2 Application Server 5.2.1.
  6. If you have a Composite Application Archive (CAR) file in AS 5.1.0, you can manually deploy using the management console of AS 5.2.1. See the topic on Creating and Deploying Carbon Applications for instructions. Alternatively, without using the management console of AS 5.2.1, you can directly copy the following directories:

    1. For super tenant, copy the <AS_HOME_5.1.0>/repository/carbonapps/0/ directory to the <AS_HOME_5.2.1>/repository/deployment/server/carbonapps/ directory.

    2. For other tenants, copy the <AS_HOME_5.1.0>/repository/carbonapps/<Tenant_No> directory to the <AS_HOME_5.2.1>/repository/tenants/<Tenant_ID>/carbonapps/ directory.

Testing the upgrade




Testing the upgrade

  1. When the database upgrade scripts are executed, the following are some of the new tables that will be created in the database:
  2. Verify that all the required scenarios are working as expected as shown below. This confirms that the upgrade is successful.
    1. Start the AS 5.3.0 server instance once the configurations are done.

    2. Make sure that the server starts up fine without any errors.

    3. Test the deployed artifacts:
      1. Log in to the management console as the super tenant.

      2. Navigate to Main -> Applications -> List.

      3. Verify the web application list shown there.

      4. Invoke a web application to verify that it works.

      5. Then, navigate to Main -> Services -> List.

      6. Verify the services list shown there.

      7. Invoke a service to verify that it works.

      8. Then, navigate to Main -> Carbon Applications -> List.

      9. Verify the CApp list shown there.
    4. Verify that the Users and Roles are picked up:

      1. Navigate to Configure -> Accounts & Credentials -> Users and Roles

      2. Verify that the list of users and roles are shown correctly.

      3. View the permissions of a chosen role, and make sure that the permissions are correct.
    5. If you are using multitenancy,

      1. Log in to the management console using the super tenant credentials.

      2. Navigate to Configure -> View Tenants.

      3. Verify the tenant list shown there.

      4. Then, log in to the system as a tenant and make sure that the log in is successful.