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 22.214.171.124 and 126.96.36.199, 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 188.8.131.52 and 184.108.40.206:
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.