Testing the migration
Depending on your configuration, there are several ways of carrying out migration tests.
You should have a test/development environment to carry out migration tests. Development environments are subject to license: check your license contract or contact Adobe Campaign's sales service.
- Stop all developments in progress and carry them over to the production environment.
- Make a backup of the development environment database.
- Stop all Adobe Campaign processes on the development instance.
- Make a backup of the production environment database and restore it as a development environment.
- Before starting the Adobe Campaign services, run the freezeInstance.js cauterization script which lets you clear the database of any objects that were running when the backup was started.
- Make sure your backups are correct by trying to restore them. Make sure you can access your database, your tables, your data, etc.
- Test the migration procedure in the development environment.The full procedures are detailed in the Prerequisites for migration to Adobe Campaign 7 section.
- If the migration of the development environment is successful, you can migrate the production environment.
Due to changes made to the data structure, importing and exporting data packages is not possible between a v5 platform and a v7 platform.
The Adobe Campaign update command ( postupgrade ) lets you synchronize resources and update schemas and the database. This operation can only be carried out once and only on the application server. After synchronizing resources, the postupgrade command lets you detect whether the synchronization generates any errors or warnings.
Various options let you measure the impact from a migration and identify the potential problems. These options are to be executed:
- in the config command:
nlserver.exe config <option> -instance:<instanceName>
- or at the postupgrade:
nlserver.exe config -postupgrade <option> -instance:<instanceName>
You must use the -instance: <instanceame> option. We do not recommend using the -allinstances option.
-showCustomEntities and -showDeletedEntities options
- The -showCustomEntities option displays the list of all non-standard objects:
nlserver.exe config -showCustomEntities -instance:<instanceName>Example of a sent message:
- The -showDeletedEntities option displays the list of all the standard objects that are missing in the database or the file system. For each missing object, the path is specified.
nlserver.exe config -showDeletedEntities -instance:<instanceName>Example of a sent message:
Out of the box object 'nms:deliveryCustomizationMdl' belonging to the 'xtk:srcSchema' schema has not been found in the file system.
Integrated as standard in the postupgrade command, this process lets you display warnings and errors that could make the migration fail. If errors are displayed, the migration has not been executed. If this happens, correct all the errors then re-start the postupgrade.
You can start the verification process on its own (without migration) using the command:
nlserver.exe config -postupgrade -check -instance:<instanceName>
Please ignore all warnings and errors which have the JST-310040 code.
The following expressions are searched for (case sensitive):
|Expression||Error code||Log type||Comments|
|common.js||PU-0002||Warning||This library must not be used.|
|logon(||PU-0003||Warning||This connection method must be no longer be used. Refer to Identified web applications .|
|sql=||PU-0005||Error||This type of error leads to a migration failure. Refer to SQLData .|
|SQLDATA||PU-0006||Error||This type of error leads to a migration failure. Refer to SQLData . If you get overview-type web application error logs (migration from v6.02), refer to Web applications .|
A database and schema coherence check is also carried out.
This option lets you restore out-of-the-box objects if they had been modified. For each restored object, a backup of your changes is stored in the selected folder:
nlserver.exe config -postupgrade -restoreFactory:<backupfolder> -instance:<instanceName>
We strongly recommend using absolute folder paths and keeping the folder tree structure. For example: backupFolder\nms\srcSchema\billing.xml.
If you restart the postupgrade after a migration failure, it resumes from the same place it was stopped.