Migration procedures

Main migration stages

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

• 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 HRM operation 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 processing routines 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.

Preparation of the v7 environment

This environment is prepared by installing the U9 solution, and then integrating all the existing patches in the related X3 folder.
 A U9 solution cannot and must not be installed on a former solution.

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, 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.

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

Activity code values may need to be modified in the folder record, 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.

Folder revalidation

Revalidating the folder transforms the structure of the Sage X3 People dictionary, then of the setup tables, then the data tables, of the previous version in order to bring the structure up to the U9 level while transferring the data. To revalidate the folder, click the Validation from the folder management function.

Revalidating the folder 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.

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 routine. To consider the migration as completed, these stages must have been carried out.

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 processing routines 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 processing routines 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 the volume of 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 effect, when there is no migration plan, the validation operation of the folder 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. Pending. If it were the case, the plan would be 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.

 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. Caution, this number is limited by the number of batch tasks likely to be executed simultaneously (defined in the function of batch server setup), 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 will be handled manually.
• An indicator stating if post-migration 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 has the value of the NBRTACSIM parameter or, if it does not exist, it has 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 in the screen associated with the migration plan. Specific buttons make it possible to globally control the running of the plan:

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

Each line of the plan 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 migration steps make it possible to split the functional migration. 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 the very first to be executed. It is not used up to now and makes it possible for specific procedures to be executed before the migration itself.
• The common data step makes it possible to migrate data used by the following steps.
• The module step makes it possible to carry 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 launching will be carried out by 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.

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 in to check and adapt some functional setups. This aspect is described in the documentation on the functional postrequisites.