Genpact Cora Knowledge Center


Migrating from Previous Versions to Cora SeQuence V9.x



Cora SeQuence V9.0 architecture has been restructured into independent modules. These modules are building blocks for building applications, which you can deploy separately. As a result of these structural changes, it is not possible to upgrade Cora SeQuence directly from previous versions to V9.x

You first need to upgrade your database to V8.8, and only then you can follow a migration path, using SQL scripts to migrate data from your previous database and performing the V9.x application deployment.

Cora SeQuence V9.0 application deployment requires fresh servers.

Migration flow

Main steps required to migrate your system. 

Migration stepDetails and links to documentation
1Migration readinessMake sure that your system is ready for migration.
For more details, see this article.
2PrerequisitesMake sure that: 
  • Your database was upgraded to V8.8.
  • You review all the breaking changes relevant to the version you are upgrading from.
    For more details, see this article.  
  • The application servers are clean servers—servers that did not have Cora SeQuence installed on them previously.
Make sure that the database server has at least the same amount of free disk space as the size of the current Cora SeQuence database.
3Database migration  Migrate database (see procedure below)
4V9.x deployment
  1. Install pre-built applications or Build customized applications 
  2. Deploy applications
Post-migration steps
  • Delete unused tables
  • Find activities that use the Shared Resources folder
  • Remove redundancy property from jobs

For more details, see this article.

Migrate database 

You migrate the database using SQL scripts.

  1. Download the migration scripts.
  2. Back up the database.
  3. To make sure that applications from the previous version do not connect to the V9.x database, make sure that:
    1. You shut down all the application servers, and leave only the database server on.
    2. Do one of the following:
      • Rename the database with a different name.
      • Restore the database as a new database and use the restored database with a new name.
  4. To avoid a full transaction log, change the database recovery model to Simple.
  5. Run the following scripts:
    1. 01 - Pre-Migration script JES.sql
    2. 02 - Database.sql
    3. 03 - Objects.sql
    4. 04 - Data.sql
    5. 05 - Fill Global Solution Tables.sql
    6. 06 - Consolidate UWF Tables.sql

      Depending on the amount of data in the USL and UWF tables, the Fill Global Solution Tables and Consolidate UWF Tables scripts can take several hours to run.

    7. 07 - JES Migration script.sql

      In case there are jobs that should not be redundant, change their redundancy configuration after the migration is completed.
      For more details, see the Next steps section.

    8. 08 - End Migration script JES.sql
  6. To verify that the database migration was successful, run the following command: SELECT fldVersion FROM tblCompanyParam
    Expected result: 9.0.0.x
  7. If relevant, change the database recovery model back to the required option.

Next steps

After the migration process ends, review the post-migration procedures, to decide if they are relevant for your implementation.

For more details, see this article.

Rollback to previous version

  1. Restore the backed up database to previous state.