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:
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.
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.
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:
Open a private workspace (ex-transaction).
Browse through objects using query tools, navigation trees and diagrams.
Perform insignificant updates (ex: change a character in a comment value, slightly move an object in a diagram...).
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
Creation tool
The implementation has changed (HOPEX V2R1).
A tool converting custom creation tool to the new format in provided.
It is mandatory to review declarative creation tools (MetaWizard, Category Specification/_Kindprovider) and coded tool (java..)
Person assignment
The implementation has changed (HOPEX V1R3).
A tool converting user and assignments to the new format is provided.
It is mandatory to review the user configuration (connection parameters, administrator privilege) unless a review was already performed in HOPEX V2. Note that with HOPEX, it is recommended to set options and command line at profile level.
Profiles
The features 'Metamodel access management' and 'Metamodel filter' (MEGA 2009 SP5) are replaced with a management of permission.
A tool converting profiles to the new format is provided.
It is mandatory to review the profile configuration unless a review was already performed in HOPEX V2. This review should be based on initial functional specifications. Note that profiles are renamed if the
Workflows
Configuration and implementation has evolved significantly between MEGA 2009 and HOPEX V2 and to a lesser extent between HOPEX V1R2-V1R3 and HOPEX V2. Tools converting definition of workflows to the new format is provided. It also converts data related to workflow. It is recommended to review the workflow configuration if workflows have been customized. This review should be based on based on initial functional specifications. Note that the change to profile assignment can impact customization performed in HOPEX V1R2-V1R3.
API script
The metamodel has changed.
No tool can be provided for specific code. No detailed indication is provided.
It is recommended to review the customized macros and applications using API script in particular for Administration APIs. This review should be based on initial functional specifications. Note that creation of threads in java code is not supported.
Authentication
A new authentication framework called UAS is available.
It is compatible with basic authentication and its 3 implementations (MEGA, LDAP, Windows).
Fully customized authentication provider can work provided custom code is installed and called by configuration.
Windows authentication based on sample delegatedlogin_windows.aspx.cs is no longer supported. Standard UAS provider for Windows Authentication must be used. Login data need reprocessing. See KB 00007532 in MEGA Community.
 
The above list is not exhaustive.