Best practices for IBM TRIRIGA application upgrade – Part 4
In our last and final post on this series, we talk about record data tips and IBM TRIRIGA application upgrade delivery best practices that ValuD recommends.
Record Data Tips:
Turn to a senior TRIRIGA technical expert to determine how to migrate your hierarchical and transactional data. Document the recommendations as a reference point for future upgrades. In general, ValuD recommends that you
- For Hierarchical Data, Object migrate Classification data and Data Migrate portfolio data
- For Transactional Data, migrate only certain types of data such as ClassLoader. Do not attempt to object migrate module data such as People, Asset, Lease etc., as it could lead to association issues or duplication.
IBM TRIRIGA Application Upgrade delivery process
After making the changes in the Target environment, you will need to move those changes to the Source environment to commence the testing process (You cannot test in the Target environment as it does not contain any data. Therefore, you will need to test in the Source environment only).
OOTB TRIRIGA comes with full package capabilities to move all the metadata at once but ValuD recommends that you move the metadata incrementally by creating a series of smaller packages. Though this involves more time and effort, the risk involved is much lower versus moving the entire package at once.
- If moving the metadata incrementally, make note of the dependencies involved and ensure strict adherence.
- If moving the entire metadata at once then consider moving the record data and security groups separately.
Application Upgrade Tips
Renaming Objects: Do not take up a renaming project in parallel with your IBM TRIRIGA application upgrade. We recommend that you keep the names of the TRIRIGA modified objects as-is and consider relabeling back to the OOTB only after the completion of the upgrade process.
Resource expertise: Always enlist the help of a senior IBM TRIRIGA expert to complete your object migration process.
- Expert knowledge of TRIRIGA is required to handle critical tasks such as distinguishing between existing and new objects, validation and import.
- While accessing and reading the Object Migration log files (through the Admin console), an inexperienced TRIRIGA resource might not be aware of the fact that two passes need to be done in order to have a complete successful run of an Object Migration package and might stop at just one pass.
Dry Runs: ValuD recommends that you conduct a minimum of 3- 4 dry runs by setting up a copy of the production environment and running these packages several times in this environment. This will help:
- Identify effectiveness of the Object Migration packages
- Establish a timeline for the delivery duration
- Test the delivery documentation for any missing tasks and
- Create readiness for the IT group
For more information on ValuD’s IBM TRIRIGA upgrade best practices, watch our webinar.