Page Comparison

...

1. Syndeia 3.2 installed and running on a server. This is our source server (database).

2. Syndeia 3.3 installed and running on a server. This is our target server (database).

3. The migration process requires an additional syndeia_cloud_devops keyspace on the target 3.3 server. The schema/gen-schema.cql file contained in this utility has the required CQL statements to create the schema and tables. Please run this utility from a CQL shell or using a tool similar to DataStax Devcenter. This keyspace has three sets of tables - a pre_stage_* set, a migrate_stage_* set, and a duplicate_* set of tables.

4. Since we might be dealing with huge data, we also need to tweak two Cassandra timeout variables in conf/cassandra.yaml file namely:
   read_request_timeout_in_ms (how long the coordinator should wait for read operations to complete) - whose default value is 5000, but we have to increase it to 60000, and,
   request_timeout_in_ms (the default timeout for other, miscellaneous operations) - whose default value is 10000, but we have to increase it to 120000

5. Download the Syndeia-Migration-3.3-Utility from the Syndeia Cloud download page that you were provided with your Syndeia 3.3 licenses.

6. Download the Syndeia, 3.3 Standalone client from the Syndeia client download page that you were provided with your Syndeia 3.3 licenses.

7. The user who is doing the migration should be an admin user on Syndeia Cloud 3.2 and 3.3. Additionally, the user should have the credentials of each external repository (server) with permission to read all the data in that repository that was connected using Syndeia. For example, if Syndeia Cloud 3.2 has Syndeia relations to Jira issues, then the admin running the migration utility should have permissions to access the given Jira project and the issues. This is required during the enhancement phase of the migration.

...