Overview
The entire upgrade process consists mainly of data migration, which is divided into particular steps to ensure the flexibility and failover of the upgrade. This document describes the current steps in detail, see the general description of Upgrading from YSoft SafeQ 5 to Dispatcher Paragon and The YSoft SafeQ 5 to Dispatcher Paragon Upgrade Tool to see how upgrading and data migration in steps work in general.
Particular upgrade steps are divided into schemes according to the migration areas:
- CLUSTER – the scheme for cluster management steps which is loaded automatically for tenant_1 a database scheme
- TENANT – the scheme for upgrading a tenant database
- DWH – the scheme for upgrading a tenant's warehouse database
Step Overview
CLUSTER.INITIALIZE
Creates database entities for migration and cleans logging tables.
CLUSTER.COMMON
Prepares common data for migration (especially identifiers).
CLUSTER.CONFIGURATIONS
Migrates the appropriate configuration of YSoft SafeQ 5 into the cluster management scheme (the common configuration for all tenants).
This step is run only for the default first tenant, i.e., it is not run for additional tenant schemes.
CLUSTER.POOL
Migrates data about the file pool to be deleted.
TENANT.INITIALIZE
Creates database entities for migration and cleans logging tables.
TENANT.COMMON
Prepares common data for migration (especially identificators).
TENANT.CONFIGURATIONS
Migrates the appropriate configuration of YSoft SafeQ 5 into the tenants scheme (the configuration for each tenant).
TENANT.USERS
Migrates users' data about users, user roles, rights, etc.
TENANT.DEVICES
Migrates device data, including terminals, Spooler Controllers, and device groups.
Migration of ORS servers
All valid and active ORS servers are migrated as Spooler Controllers while the upgrade mechanism expects there must be at least one Spooler Controller in the destination Dispatcher Paragon. It means Dispatcher Paragon must be installed with a local Spooler Controller or there must exist at least one ORS server in Dispatcher Paragon 5. If the condition is not fulfilled, the migration ends with a FAILED status.
Device assignment to Spooler Controller is migrated according to the following rules:
- The device from a non-ORS device group is assigned
- to local Spooler Controller if it exists, or
- to the first migrated Spooler Controller (i.e., the first ORS group or local Spooler Controller installed with Dispatcher Paragon).
- The device from the ORS device group is assigned to Spooler Controller created from that ORS group.
During the migration, the Spooler Controllers migrated from ORS groups are only created in the database, it is necessary to install them manually at the same IP address with the same GUID.
Migration of device accounting
Because there is a slightly different accounting setting in Dispatcher Paragon, it is possible that migrated devices will have different accounting than the original devices. See accounting translation details. If the accounting was changed for a device during the migration, there is an appropriate message in the upgrade report, and the Upgrade tool returns WARNING status or a warning message is displayed in the case of the Server installer.
Migration of hardware terminals
The hardware terminal type "Hardware terminal professional version 3.5" is not supported in Dispatcher Paragon, so in the case of this terminal migration, the appropriate device is migrated as "device without terminal", and a WARNING status or a warning message is displayed in the case of the Server installer.
TENANT.DEVICE_TEMPLATES
Migrates device templates data.
TENANT.QUEUES
Migrates device direct and user shared queues data.
TENANT.PRICELISTS
Migrates price list data.
TENANT.PROJECTS
Migrates the billing code data.
TENANT.JOBS
Migrates jobs metadata mainly because of reports and statistics.
All jobs with any possible statuses are migrated as DELETED with no previews because it is not possible to migrate spooled job data due to the radically different architecture of Dispatcher Paragon. Users have to send their jobs again after a successful upgrade to be able to print any previously spooled jobs again (even the favorite ones). Also, there a situation can occur when jobs are accounted in YSoft SafeQ 5 but are not part of statistics yet.
TENANT.STATS
Migrates the metadata of statistics reports (Web reports, Management reports, scheduled reports to email, file, etc.).
TENANT.RBE_RULES
Migrates the RBE data file from YSoft SafeQ 5 file format into the Dispatcher Paragon database.
TENANT.SCAN_WORKFLOWS
Migrates scanning workflows and related data (scan parameters, scan accesses).
Scan to email
For the workflows type Scan to email in YSoft SafeQ 5, you need to define two parameters – from and to – which are used for specifying the sender and recipient email addresses. If either one of them happens to be empty after migration into Dispatcher Paragon, you will have defined user inputs %senderEmail% and %recipientEmail% respectively.
From Build 60, there is an issue that causes email workflows to fail ("Unsupported account type [0]." error message in Dispatcher Paragon Workflow Processing Server). The issue can be fixed manually by opening the connector for edition, making some changes so the Save button appears, and saving the connector.
Scan to script
For the workflows type Scan to script in YSoft SafeQ 5, you need to define the parameter targetDir. After the migration is done in Dispatcher Paragon, the value of this parameter will populate the field Target folder in the workflow definition for this workflow.
The administrator must verify that this field contains the only absolute path.
The relevant message will be written in the Upgrade report file generated during the migration process.
DWH.INITIALIZE
Creates database entities for migration and cleans logging tables.
DWH.COMMON
Prepares common data used by the migration process (mainly, ID conversion tables).
DWH.REPORTS
Migrates the data of reports.
DWH.STATS
Migrates the metadata of statistics reports (Web reports, Management reports, etc.).