Migration Process New from S 39.5.0

General

Information

• From Server S 39.5.0, there is a new migration process integrated in PLANTA, replacing the previous hotfix process.
  • Instead of loading SQL files, there is now a framework written in Python, that serves to carry out updates.
  • This is done with the help of so called migration packets. They carry out changes to the existing PLANTA installation, especially the database.
  • In order to start the migration, the server has to be started in migration mode.
    • The server starts a new internal session with the MIGRATION PLANTA user. As a result, all new records or changes that are created/made to the customizing in migration mode, have the MIGRATION change/creation user. See also the entry under Attention below.
  • When starting the migration, all mandatory packets are run automatically. All further packets must be run manually. For more information, see migration process.

General

Information

• From Server S 39.5.0, there is a new migration process integrated in PLANTA, replacing the previous hotfix process.
  • Instead of loading SQL files, there is now a framework written in Python, that serves to carry out updates.
  • This is done with the help of so called migration packets. They carry out changes to the existing PLANTA installation, especially the database.
  • In order to start the migration, the server has to be started in migration mode.
    • The server starts a new internal session with the MIGRATION PLANTA user. As a result, all new records or changes that are created/made to the customizing in migration mode, have the MIGRATION change/creation user. See also the entry under Attention below.
  • Upon starting the migration, all mandatory packets are run automatically. All further packets must be run manually. For more information, see migration process.

• NEW If the MIGRATION user and the persons assigned to it are deleted, they are recreated automatically in the next update.

NEW If the MIGRATION user is deleted, it is recreated automatically during the next update. This does not apply to the person assigned to the migration user. This person must not be deleted. If it is deleted anyway, the migration cannot be carried out.

The MIGRATION user and the person assigned to the user must not be deleted! If they are deleted anyway, the migration cannot be carried out.

• To improve performance, it is recommended for MSSQL systems to switch to the RECOVERY SIMPLE recovery model before migration:
  ALTER DATABASE <PLANTA_DB_USER> SET RECOVERY SIMPLE
  After completed migration, the recovery model should be reset to the initial model. This is the standard model of the database.
• Which migration packets are delivered with the required server release, can be checked under Release Notes.
• If there are problems in the sense that available Python modules cannot be loaded (e.g. in the 'FillMigrationRuleTable’ migration script), this can be resolved by running the CreateFolderPacket packet in the Cross Release Packets module manually.

Which migration packets are delivered with the required server release, can be checked under Release Notes.

If there are problems in the sense that available Python modules cannot be loaded (e.g. in the 'FillMigrationRuleTable’ migration script), this can be resolved by running the CreateFolderPacket packet in the Cross Release Packets module manually.

Information

• The server comes with a new mode for the implementation of the migration, the so called migration mode.
  • In the Migration mode, migration packets with upon system start parameter = as well as done = are opened.
  • While the server is in migration mode, no client can connect to this server.
  • After implementation of the migration, the server is shut down automatically.
• NEW The migration is started by opening planta_migration.bat or ./planta_migration.sh in the server installation directory.
  • The migrate parameter is ignored from here on.

Information

• The server comes with a new mode for the implementation of the migration, the so called migration mode.
  • In the Migration mode, migration packets with upon system start parameter = as well as done = are opened.
  • While the server is in migration mode, no client can connect to this server.
  • After implementation of the migration, the server is shut down automatically.
• The server can be started in two ways:
  • The planta_server.bat or planta_server.sh is started with the -migrate true console parameter.
  • Set the migrate parameter in the /config/globals.conf to true and start the server regularly. In order to be able to work with the system, the server must be started in regular mode again after the migration. For this purpose, the parameter must be set to false and the server must be restarted, depending on whether the parameter has been set as console parameter or in the globals.conf.
  • Since the console is set to false by default, it can simply be omitted.

Notes

• As an alternative to the migration mode, migration packets can also be run in the program (on the surface) via the following modules.
  • In the Special Functions module in the Migration packets panel
  • Overview of all Previous Runs
• After carrying out the migration packets in the system, the server or the server service must be restarted and the migration results must be checked.

Notes

• As an alternative to the migration mode, migration packets can also be run in the program (on the surface) via the following modules.
  • In the Special Functions module in the Migration packets panel
  • Overview of all Previous Runs
• After carrying out the migration packets in the system, the server or the server service must be restarted and the migration results must be checked.

Notes

• As an alternative to the migration mode, migration packets can also be run in the program (on the surface) via the following modules.
  • Migration Packets
  • Overview of all Previous Runs
• After carrying out the migration packets in the system, the server or the server service must be restarted and the migration results must be checked.

Notes

• As an alternative to the migration mode, migration packets can also be run in the program (on the surface) via the following modules.
  • Overview Of The Migration Packets
  • Overview of all Previous Runs
  • After carrying out the migration packets in the system, the server or the server service must be restarted and the migration results must be checked.

What happens if the server is started in migration mode?

• NEW The migration parameters must be contained in a parameter file.
  • The parameter file should only be created and adjusted by experienced users.
  • An example parameter file is located under config/migration/migration.par.
• NEW The planta_migration script has a mandatory parameter: -c / --migration-config.
  • This parameter must be the path (relative from the server directory) to the migration parameter file.
  • There must not be any blank spaces contained in this path!
• NEW To start the migration, the planta_migration script must be run in the server directory of the created parameter file: planta_migration -c "Name of the parameter file"
  • The migration process should only be initiated by experienced users.
• The server starts a new internal session with the Migration PLANTA user.
  • Therefore, all new records or changes that are created/made to the customizing in migration mode have the Migration change/creation user.
  • Please note that for this reason the Migration user must not be deleted.
• It will be searched for new migration packets on the file system. The migration packets will then be executed and information on them will be saved in the database.
• After the file system has been searched, the packets will be executed.

What happens if the server is started in migration mode?

• The server starts a new internal session with the Migration PLANTA user.
  • Therefore, all new records or changes that are created/made to the customizing in migration mode have the Migration change/creation user.
  • Please note that for this reason the Migration user must not be deleted.
• The start_migration.py file from the /py/planta_de/ppms/ subfolder of the server directory is run.
• The StartupRunner class from the /py/ppms/migration/startup.py file is initialized by start_migration.py and the run() method is opened.
• It will be searched for new migration packets on the file system. The migration packets will then be executed and information on them will be saved in the database.
• After the file system has been searched, the packets will be executed.

Migration Parameters

Information

• The parameters required for the migration are specified in a parameter file.
• Structure of the parameter file:

  --migration-components
     Server
     Customizing hotfix
     Customizing
     Customer
     Before DB Import
     After DB Import
  
  --abort-on-failure
     

Section	Explanation
migration-components	Here, the components that are to be migrated are specified.
abort-on-failure	If this option is available, the migration is aborted as soon as a migration packet fails.

• The possible components stem from the __init__py of the respective migration directories.
• The specified components determine the update type of the migration. It is therefore possible to, e.g., only migrate the customizing or only the Server component.
• The parameter file does not only give the components to be migrated but also the sequence in which is migrated.
• All packets that do not fall within the list of specified components receive the Not relevant status.

Attention

• In the example parameter file under config/migration/migration.par, all components are listed that are theoretically possible. These components must necessarily be adjusted to the actual conditions and irrelevant components must be deleted before the migration.