Check upgraded data
It is highly recommended to back up each environment once it has been upgraded.
The standard installation and upgrading process takes care of all the conversions that can be automated. Technically speaking, conversion success is guaranteed by:
1. The correct execution of the environment automatic upgrade processing.
If errors are met at this step, the migration process must be stopped so that a diagnosis is made. Check carefully the Mega error log.
2. The correct execution of all mandatory conversions for the system database.
If errors are met at this step, the migration process must be stopped so that a diagnosis is made.
3. The correct execution of all mandatory conversions for each data repository.
If errors are met at this step, the migration process must be stopped so that a diagnosis is made.
After complete execution of the migration process, it is highly recommended to check data and customizations through:
• First control of migration: run a quick tour to check that data looks correct.
• Check of data consistency: run utilities to enforce rules regarding data structure.
• Other checking indications.
First control of migration
It is highly recommended to run a quick tour and check that upgraded data looks correct. Of course, this kind of check cannot be exhaustive, but it usually enables to have a first feedback and quickly identify certain migration issues.
Example of scenario:
1. Open a private workspace (ex-transaction).
2. Browse through objects using query tools, navigation trees and diagrams.
3. Perform insignificant updates (ex: change a character in a comment value, slightly move an object in a diagram...).
4. Dispatch private workspace.
Check data modelling consistency
In previous versions, many things were tolerated, although not recommended. In order to ensure better consistency, there is a need for a thorough review of the repository content and, potentially, some cleaning and tidying tasks to perform. This should be considered as a separate project.
Other checking indications
If extensions were made to the metamodel, they must be reviewed regarding the structuring rules described above. A particular attention must be paid to the orientation of MetaAssociations as it governs the behaviors of the related objects.
If customizations have been made (property pages layer, diagram configuration layer, templates, programs based on script APIs…), a specific check is required based on initial customization specifications. As customizations are often based upon standard layers, they may not be ready to use and they may have a different look and feel. This check requires functional and platform development skills.
|
Topic
|
Comment
|
|
Web Desktop related to GRC Solutions
|
For certain solutions (HOPEX Enterprise Risk Management, HOPEX Internal Control, HOPEX LDC), the web desktop have changed.
It is required to review desktop execution if customization have been made or if projects wants to keep classic desktops for compatibility (not recommended). Review should be based on initial functional specifications. This is a customization expert work.
|
|
Profiles
|
It is recommended to review the profile execution for custom profiles. Review should be based on initial functional specifications.
|
|
Custom API code
|
It is recommended to review the customized macros and applications using API script in particular for Administration APIs. Review should be based on initial functional specifications.
|
|
Custom authentication
|
It is required to review authentication in case of fully customized authentication provider. Review should be based on initial functional specifications.
|
|
Web services
|
It is required to review web services execution. Review should be based on initial functional specifications.
|
The above list is not exhaustive.