Table of Contents
The process of an xentral server move (moving an xentral system to a another server or provider) consists of 10 steps. Here is first an overview of the process - each step is explained in more detail below.
- Disable the process starter of the legacy system globally
- Save the data of the legacy system
- Install new system
- Set up CRON job
- Insert database into new system
- Import file data into the new system (userdata) and make corrections, if necessary make
- Update new system
- Connect hardware to the new system
- Finish testing
- Enable the new system's process starter
Disable legacy system process starters: The process starters of the legacy system will be globally deactivated. This option can be found under Administration > Settings > System > Process starter. Select Globally deactivate process starter on the right.
Backup legacy system data: The data is backed up with a system backup. Alternatively, the data can also be backed up using a DB dump and a copy of the userdata folder can be backed up. It is recommended that you pack both the userdata folder and the database in an archive format (e.g. tar.gz or zip).
For details, see the article Data Relocation.
Note: The php file "cache_service.php" does not need to be taken along. This is a cache file that is automatically recreated with the next update. More information about the PHP and CLI customization you can find at here.
- Install new system: On the new server, the new system will be installed. To do this, please download the OperSource version (OS version) in the download section of the website (download) and install it according to instructions. By importing the license key, the correct version and license will be restored later.
Note: If possible, the same database name as the Legacy system should be used. See also point 6.
CRON job setup: On the new server should now be ensured, that the so-called heartbeat cronjob is running, which is the trigger for the process starter mechanism in xentral. All information about this can be found in the article: Setting up the heartbeat cronjob.
Import database into the new system: The database from the legacy system is now imported into the new system. The following should be done after the import, the number of tables should be checked to make sure that all tables were exported and imported correctly. Randomly check the number of rows of important tables (e.g. address, article, order).
The license data was also transferred to the new system with the database.
For more notes on this point, see also the article Data migration.
- Import file data into the new system: The data of the folder userdata will be imported into the new system. If possible, it is useful for a server-to-server connection (e.g., with scp) instead of saving the data locally (on your own computer) and then uploading it to the new computer.
After the transfer on the basis of the total size of the folder (you -hs) and the number of files should be checked to check whether the transfer is complete.
Due to the transfer of the folder often the ownership/write permissions of the Folder structure are not correct. These can then be quickly adjusted. More detailed information about this is provided in the article Data move.
Influence of the database name In the userdata folder there are subfolders in which there are in turn subfolders whose names depend on the old database. These folders must be renamed to the new database name.
Mostly the following folders are affected:
- In the dms folder
- In the folder emailbackup (If present)
- In the pdfarchive folder
- In the pdfmirror folder
If there are other folders, they must also be checked. Also, existing files, which lead the database name in the file name must be renamed, for example, the stationery. sinf if necessary to adjust or reconfigure.
Custom-created fonts will be copied by the move from the folder www/lib/pdf/font/unifont. The fonts should therefore now be manually added to the system. Note on the procedure can be found in article Stationery.
More detailed information on this can also be found in the article Data migration.
- Update new system. Now the new system can be updated for the first time, thereby on basis of the license data also the correct license is activated and if necessary, missing modules reloaded.
See article Access to the update server
Please note: The legacy system now has no valid license anymore.
- Connect hardware to the new system After converting a server installation. If there is a change of address (Suddomain or DOmain), the local connections of the hardware must be converted. This includes e.g. scanners/cameras or label printers to adapter boxes or printer spoolers.
Basically, the same steps are necessary for this as for an installation of the devices, only that the first steps can be skipped. See also article Printer Quick Start.
In principle however only the URLs and if necessary key must be adapted, which are deposited with the Spooler in the settings, and with the adapter box over the Config file are given.
- Final checks. It makes sense to perform some final checks before the system goes back into production operation:
- Check if any users in the personal settings still reference the Legacy system (home page).
- Check if the webserver has access to the file system (userdata): To do this via the interface of a file (e.g. of an address). If this is subsequently downloaded and has a file size of 0 bytes, the access rights are probably wrong. If you can open the file, everything has worked. Otherwise, see the article data move, for example, under final adjustments.
- Activate process starters of the new system The process starters of the new System will be activated globally. This option can be found under Administration → Settings → System → Process starters on the right in the action menu Activate process starters globally.