I am in the next step of our upgrade from 9.3.3 to 18.104.22.168 and ready to migrate our Planning applications. I have read many of the posts related to this and have a general list of steps, but I have slightly different situation than what I have seen posted before.
To summarize, we have installed 22.214.171.124 on new servers. Our old 9.3.3 is still up and running on different environment. I have sucessfully completed the following:
1. Foundation Services/Shared Services installed and up and running and users/groups successfully migrated.
2. Essbase and EAS installed and up and running. All Essbase applications (except for the Planning apps), have been successfully migrated from 9.3.3 to 126.96.36.199.
3. Planning has been installed and is up and running. While there are no Planning apps in the new system, I can open the Planning Administrator via WorkSpace.
So the next step is to get my Planning apps moved/migrated from the 9.3.3 environment to the new 188.8.131.52.
To complicate matters, we are switching from SQL Server repository in 9.3.3 to Oracle in our new 184.108.40.206. So the first thing we did was to create a new Oracle schema for our Planning app repository and using SQL Developer migrate wizard, we copied/migrated the tables and data from the old SQL Server to Oracle. It appears that all the tables and data were successfully copied into Oracle.
Our old Planning application is called PlanTest. The application owner is a native user called planadm. My intended migration plan (and my questions) are:
1. Do I create a new blank Planning app called PlanTest using native account planamd in 220.127.116.11?
2. If I use my new Oracle repository for this blank app, will it wipe out the old converted data or will it try to upgrade/migrate it?
3. Or..should I take a backup of my new converted repository first. Then drop/recreate the Oracle Schema (so no tables) and let Planning build the repository when I create the blank Planning app? Then capture the owner SID in the new HSP_USER table. Stop Planning. Then overlay the database backup of 9.3.3 over the newly created repository and replace the owner SID info. Then Restart Planning.
** My concern: Is the Planning app repository table structures the same between 9.3.3 and 18.104.22.168?
4. Open Planning and hope that the application PlanTest appears!
5. Use Planning upgrade Wizard to finish the migration and upgrade the repository.
6. Push/Create app to Essbase.
7. Export data from old app to .txt load file and reload into new Planning cube.
8. Convert/Migrate Business Rules using info from John's blog.
I am sure I missed something. Any suggestions or comments on these steps would be appreciated. Bottom line is I need to get this app (and several others) migrated successfully with all metadata, security, forms, rules etc. working. Rebuilding them from scratch is NOT an option.
Also, to clarify. This is a Classic Planning app. We are not using EPMA.
It would probably make things even simpler if the application owner was changed to the default admin account before upgrading.
Anyway, it has been covered before but
create a blank planning app (doesn't matter about the options) with planadm
store the SID code in the HSP_USERS table
stop planning, drop the schema, import the 9.3.3 to the same schema,
update the SID in the HSP_USER to the one stored.
and so on
** My concern: Is the Planning app repository table structures the same between 9.3.3 and 22.214.171.124? --- No its not same , but you don't have to worry about it..As your 5th Step will take care of this (Under upgrade process we have sql scripts which will upgrade your planning application from 9.3.3 to 126.96.36.199 and at last to 188.8.131.52 step by step)
Rest -- John has already updated..
Following the steps, the upgrade/migration of the Planning application worked successfully. The app and forms were all migrated and was able to push to Essbase application successfully. The only issue was security. While the users/groups seem to appear in the migrated Planning app, none of their security access/filter info migrated. We have Planning security defined down to the member level in the application and it appears none of that successfully migrated, so we would need to manually re-assign all of that security. Any thoughts of what may have happend or step I may have missed?
Also have moved on to attempt migration of the Business Rules to Calc Manager. Using John's 2nd alternative method from his blog, I export the rule from 9.3.3 EAS to HBRRules.xml file, copy it to the appropriate 184.108.40.206 folder, select "Migrate" on the PlanTest planning app in Calc Manager, select the app and Plan type and all seems well with the Import screen even indicating that the Rule and variables were Inserted. But I never see the rule appear. Could this be an "owner" issue or is there something I need to do to the .xml file before the migration step?
If there is an issue with security then it probably doesn't match between Shared Services and Planning, it all depends how you migrated the Shared Services security, there is also the updateusers utility which is an option to try and sync security.
If the business rules methods does not work then you may have to use the other methods available.
I suspected that may be the problem. Since Shared Services was a clean install, we imported all of our users/groups via the hssmigratedata.zip file from our Production environment since our old test environment only had a few users. Howerver, this Planning app was migrated from our Test environment, thus the out of sync security. So I assume if I were to migrate our other Planning apps from our old Production environment, I would not run into the security issue? That being said, if I were to use the updateusers utility to sync security, I assume I run it after the Planning app has been migrated?
As for the business rule issue. I will research the other methods. One question is the version of 220.127.116.11. I have only installed the base version. I have not applied any patches. Would applying the .300 patch possibly fix any migration issues?
Have you gone through Oracle whitepaper for migration to Calc manager : Hyperion Business Rules (HBR) to Calculation Manager Migration White Paper (Doc ID 1528121.1)?
It covers prerequisites & all recommended methods.Also, It is recommended to be on at least Oracle Hyperion Planning Patch Set Update 18.104.22.168.300 and Oracle Hyperion Calculation Manager Patch Set Update 22.214.171.124.300. (Not sure if this can fix your issue)