Migrating from Previous Versions to Cora SeQuence V9.x

V9.x

Overview

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.

NOTE
Cora SeQuence V9.0 application deployment requires fresh servers.

Migration flow

Main steps required to migrate your system.

	Migration step	Details and links to documentation
1	Migration readiness	Make sure that your system is ready for migration. For more details, see this article.
2	Prerequisites	Make 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. NOTE 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.
3	Database migration	Migrate database (see procedure below)
4	V9.x deployment	Install pre-built applications or Build customized applications Deploy applications
5	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.

Download the migration scripts.
Back up the database.
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.
To avoid a full transaction log, change the database recovery model to Simple.
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
  NOTE
  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
  NOTE
  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
To verify that the database migration was successful, run the following command: SELECT fldVersion FROM tblCompanyParam
Expected result: 9.0.0.x
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

Restore the backed up database to previous state.