Request a Consultation

CheckPoint Consulting Blog

Post-upgrade migration of security from one version of Hyperion to another can be challenging. Ideally, security is migrated as part of the upgrade as documented in the upgrade steps, however there are times between the initial upgrade and go-live that requires a second migration, with a large amount of security changing and parallel maintenance either not practical or simply neglected.

There are times where this is as simple as export / import, however often the Role IDs and directory structure changes, leaving you without a clear upgrade path.

These steps can help. My example was performed between 11.1.2.0 and 11.1.2.4, however the same basic approach should be possible for most versions.

Export your source security

Perform a normal LCM export on the source system and save to your local computer, making the name clear that it is the source system

Export your target security

Perform a normal LCM export on the target system and save to your local computer, making the name clear that it is the target system

Extract both exports locally

The exports should be in zip format (however if the source system is old enough, you may have to copy it from the server in non-zipped format

Compare / Create roles in each system to ensure you can identify role IDs

This step will be rather time consuming. This is my example for Planning between 11.1.2.0 and 11.1.2.4:

Screen Shot 2017-09-28 at 8.23.58 AM

I created the above by provisioning a test user in each environment with one role at a time and exporting only that user, then examining the contents of the security export. Again – this is a tedious, but necessary step. Repeat separately for each product / role in the security folder.

Move source roles into target folder structure

Don’t copy entire files as the formatting has likely changed. Instead, open the target files and replace the contents, making sure you keep the target file format

Search and replace

Perform search and replace for each role based on the from-to matrix you created in the steps above. BE VERY CAREFUL with this step to be sure you don’t accidentally replace lines that only partially match (i.e. Administrator and Planning Administrator are separate roles. If you replace “Administrator” globally without caution, Planning Administrator with become an Administrator or will be replaced with an invalid value). Repeat for each product.

Zip and import

Zip your target directories (giving it a new name from the export), ensuring your directory structure in the zip file matches the exported version exactly (this may become an issue with Essbase if you have different cluster names – more effort is then required to harmonize the folder structure to the new environment). You should then be able to upload and import the security to the new environment.