Update procedures 

This document describes the optimized migration procedures implemented in Sage X3 HR & Payroll.

These procedures can be performed:

  • Either by migrating from a Version 7 patch 4 solution minimum.
    In that case, refer to the technical procedure described in the Easy upgrade guide documentation (documentation only available in English).
  • Either by installing the Update 9.0.0 (or Update 9, or U9) solution, then integrating all the existing patches in its PAIE root folder.
    In that case, follow the optimized migration procedures described below.

Main migration stages

In case of migration of a folder from one major release to another, the following stages must be complied with:

  • Controls prior to the migration in the original folder. These controls can be carried out without stopping the Sage X3 HR & Payroll operations.
  • Installation of Update 9.0 (U9) in a dedicated environment.
  • The extraction of the data to be migrated from the original folder, followed by the reintegration of these data (the operation of Sage X3 HR & Payroll must be stopped and started again when migration is completed). Data extraction will be carried in a "flat" format for small folders, and using database extraction tools for larger folders.
  • Folder revalidation in the U9 environment. This revalidation can be sub-divided into several stages, using the migration plan setup. If the folder is not too bulky, defining migration plans may not prove necessary. It becomes necessary if transfer processings need to be run in parallel (to benefit from the power of a multi-processor server) and their sequencing needs to be checked using resumption marks.
  • Postmigration controls. This mainly relates to setup checking and adaptation.

The rest of the documentation describes all the steps.

Pre-migration stages

Pre-migration stages are launched in the source environment and they can be spread over a period of time, before the actual migration. In fact, they do not require the operation of Sage X3 HR & Payroll to be stopped.

The stages are the following:

  • First, it is necessary to check that the original folder is at the minimum patch level required to run a migration. This level, which can be displayed in V6 via the ? menu > About or in V7 via the Administration > Version information menu (then click a folder in the grid to access the details), must at least be:
    • patch 28 for a version 6,
    • patch 4 for a version 7,
    • functional prerequisites to the migration process. These prerequisites are described in the dedicated documentation.
  • Automated procedures can then be triggered in the original folder, via processings with names beginning with UU. These processings can be launched using the Process execution function. These processings are supplied upon request, according to the version, as a specific patch dedicated to migration. Two types of procedures are delivered:
    • Data control procedures in the original folder (control processings with names beginning with UUMGCTL). The result of this control can reveal errors or inconsistencies which needs to be corrected before launching the migration itself. This control phase can be anticipated several weeks ahead of the migration, in order to have enough time to correct the data. It will nevertheless be necessary to relaunch it to check that everything is correct just before moving to the next version. These procedures are listed in the corresponding documentation.
    • Optional feeding procedures, used to revalidate some tables by adding fields to them, then populating them (processings prior to the migration with names starting with UUMGPRE). Since these procedures are independent from one another, they can be planned over several weeks prior to migration (the operation can resume as soon as the fields have been added). The purpose of these procedures is to significantly accelerate the actual migration stages. However, not launching these procedures does not jeopardize the execution of the migration procedures. These procedures are listed in the corresponding documentation.

Copy of data and adjustment of the folder parameters

This stage corresponds to the beginning of the transfer to the next version. At this stage, the operation of the solution must be stopped: it will resume when the migration is completed.

This stage is sub-divided into 4 phases:

1. Extraction of the data from the folder to be migrated:

    • Via the extraction of data in a "flat" format for small folders. The Extraction function is used for this purpose and creates the files in the default SVG directory.
    • Via the extraction of databases for larger volumes (the format depends on the database and tool used),

2. Copy of the files of the folder to be migrated to the U9 solution,

3. Creation of a copy folder of the folder tree structure in the new environment of version 6 or 7, and import of the exported data into the new environment,

4. Creation of the folder record in the U9 environment. If the import is carried out via the console, the folder record is created automatically. On the other hand, if the import has been carried out via database tools, the folder record will have to be created manually after the import is completed.

SEEINFO These various stages can be combined into a single one. For that purpose, use theremote import wizard available in the SAFE X3 configuration console.

 SEEWARNING If the procedure must be relaunched from the import of the data into the migration folder, you must launch the TRTMIGDEL processing to clear the tables storing the migration status.

If the console import function is used, the procedure is as follows:

  • Start the console.
  • Choose the required U9 solution and display the Folders screen.
  • Click the Import button (located in the screen tool bar). A window is displayed.
  • Select the name of the folder to be imported, the directory containing the data to be imported (SVG if this is the directory that has been used to perform the extraction) and specify the other fields.
  • Launch the import by clicking OK.

Before revalidating the folders, the activity code value must be adjusted in the folder record. Setups are thus in conformity with the license. For example, to implement new functionalities controlled by new activity codes. The modification of the folder record, or its creation, will be carried out by logging to the Supervisor folder. The folder revalidation cannot be triggered without this update. This is reminded by an error message when launching the validation.

Folder revalidation

Revalidating the folder transforms the structure of the Sage X3 HR & Payroll dictionary, then of the setup tables, then the data tables, of the previous version in order to bring the structure up to the Update 9 level while transferring the data. To revalidate the folder, click the Validation button from folder management or launch the VALDOS task in query management. This performs the supervisor and functional migration of the folder, by running a comparison between the dictionary of the new version and the dictionary of the version to migrate.

SEEWARNING If a first migration test is performed on a folder including specific developments and if this migration is likely to stop on an error, setting up by default the dimension of the GTRALIG global variable to 200 (for optimization reasons) does not provide with all the last operations performed just before the migration is stopped.

You must temporarily modify the dimension formula of the GTRALIG global variable with the the value 1. The value 200 must be re-entered following the migration.

Remember to log out and then log on again in order for the value to be taken into account.

Main revalidation stages

The folder revalidation triggers the following stages in the folder to migrate:

  • Purge of some temporary or totaling tables whose re-creation will be carried out during later stages. For example, the Supervisor tables impacted by this purge are the following:
        ALSTRD
        ALISTER
        AWRKLOG
        AWRKLOGIND
        AWRKLOGMES
        ATMPTRA
  • Migration of the envelope, that is to say, the database dictionary and the supervisor tables necessary for the operating of the database (connection, user management, development environment and minimum setup). Once this migration has been carried out, it is theoretically possible to log on, even though the tables containing the flow application data are still empty.
  • Functional migration: whenever there is a change in the structure of a table, the procedure will carry out the necessary changes, eventually by assigning appropriate default values, through procedures that are sequenced in stages and phases. This is the lengthy part of the migration, the part that depends on the volume of data to migrate.
  • Postmigration processing. To consider the migration as completed, these stages must have been carried out.
  • Final deletion of temporary tables. This is a manual phase. It can be postponed, for safety reasons, as long as there is no absolute certainty that all the flow data has been correctly migrated.

Use of the migration plans

This functional migration can be lengthy when the folder is very large. Moreover, some updated tables are potentially independent and, therefore, could be migrated in parallel, thus benefiting from multi-processor architectures to accelerate this phase.

To allow this migration to be scheduled in the best way, it is possible to define a customized migration plan before launching the data validation. This migration plan is described in the Migration procedure function (called from the Supervisor folder). This function is used to define the stages, phases and procedures of the functional and supervisor migration. A migration plan corresponds to the definition of specific migration parameters (impacted folder, number of procedures that can be run in parallel, task sequencing policy, running status). A migration plan is created by recopying all the active elements of the migration procedure. This complete set of procedures is provided as a standard. It allows all the processings carried out by the standard software during the migration phase to be run exhaustively. A short description of these procedures is provided in a dedicated documentation.

It is possible, at this stage, to define specific procedures by writing complementary processings in conformity with the methodology defined in the following annex. These specific procedures will be inserted in a relevant way between the standard procedures.

Once a migration plan has been defined, it is possible to launch it, interrupt it momentarily, resume its execution, and view its progress status.

When a folder is not too large and its migration does not require any particular planning, it is not necessary to create a migration plan. In fact, when there is no migration plan, the folder validation operation will automatically create a migration plan. The code of this migration plan will be the folder code, except if this code already corresponds to a migration plan that does not have the Pending status. If this is the case, the plan is created with a predefined code under the form MIGmmddM##. mmandddare the numbers representing the month and the day of the launching, ## is a sequential number.

However, to customize the migration sequencing options, it is possible to create a migration plan with a code that must correspond to the folder name. This creation will take place in the supervisor folder before launching the folder validation. If there is such a migration plan with the status Pending,it will be used for the functional migration of the folder.

SEEINFO A plan created with a name that is different from the folder to migrate will never be used by the automatic folder validation functions. Such a plan is restricted to a manual launching.

Operation process in a migration plan

A migration plan is characterized by a folder code and 4 parameters:

  • An indicative title.
  • The number of procedures likely to be launched simultaneously. This number is a possible maximum. Only procedures that can be run in parallel will be launched simultaneously. Remember that this number is limited by the number of batch tasks likely to be executed simultaneously (defined in the batch server parameters function), the server being limited by the user license.
  • An indicator specifying whether the procedures must be launched automatically and linked according to the logic defined by the plan. If not, the sequencing of the procedures described in the plan must be carried out manually.
  • An indicator stating if postmigration procedures must be linked to the migration itself. These operations are detailed below.

If the migration plan is created by default upon folder revalidation, it is created with the following values:

  • Number of simultaneous tasks with the value of the NBRTACSIM parameter or, if it does not exist, the value 2,
  • Automatic sequence with the value Yes,
  • Postmigration operations with the value Yes.

The user can at all times modify these values from the migration plan control function.

The ordered list of the plan procedures is displayed on the screen associated with the migration plan. The plan execution can be globally controlled via specific buttons:

  • by launching its execution,
  • by momentarily interrupting the launch of new procedures,
  • by interrupting all the procedures in progress,
  • by relaunching its execution.

Each plan line materializes a step in the execution, characterized by:

  • the code of the procedure and its title,
  • the step and phase to which the procedure belongs,
  • the functional module to which the procedure is linked,
  • the execution rank.

The functional migration can be split through the migration steps. If a procedure linked to a given phase is not completed, the following phases cannot be launched. The phases are linked to the following steps:

  • The initialization step is a preliminary step that is executed before any other steps. It is not yet used and enables specific procedures to be executed before the migration itself.
  • The common data step migrates data used in the following steps.
  • The module step carries out migrations linked to each functional module. An operation belonging to this step is associated with a functional module: this association does not have any binding effect on the execution. For example, some data migrations linked to different modules can be run in parallel if they belong to the same phase. Their launch will be carried out according to the order of the modules, then of the execution ranks.

One step includes unitary procedures that are organized in phases and ranks.

  • It is considered possible for two procedures defined in the same phase to be run simultaneously. As a consequence they must be independent. The assignment of a standard procedure to a given phase cannot be changed. As long as all the procedures belonging to a phase are not completed, the following phase cannot be launched.
  • The rank order is purely a preferential launching order, but it can be modified, including for standard procedures, when the plan is defined.

Final purge of the movement tables

This phase is manual. It is triggered by the execution of the TRTMIGDEL processing from the processing execution function. Running this phase will delete all the tables with the MIG activity code.

SEEWARNING This phase cannot be reversed.Please ensure that the migration processings have been carried out successfully.

Keeping the temporary tables in the folder is compatible with the resumption of normal operations. It is therefore possible to keep these tables on-line for a few weeks of operation. Should any problem occur in the weeks following the migration, it will be possible to have the original data available for comparison or analysis purposes.

Verification further to the migration

As soon as the folder is revalidated, it can be accessed without use restriction (there can be some level of restriction if some postmigration operations have been postponed).

The only remaining task is to check and adapt some functional setups. This aspect is described in the documentation on the functional postrequisites.