Good afternoon user4063415 -
The easiest way (if it works) is to keep your file system completely in tact - port it in it's entirety over to your new server and update the EPM System Registry host name as needed. You'll also need to ensure all of your internal pointers for scripts/automation and possibly 3rd party tools using Essbase (i.e. Planning, HPCM, etc..) are reset to the new Essbase server name.
Here's the snippet from the 22.214.171.124 docs on updating host names:
To update the host name value in the Shared Services Registry:
From EPM_ORACLE_INSTANCE/bin, run epmsys_registry.bat|.sh updatehost oldHostName newHostName
Restart all EPM System components on all machines.
If that doesn't work - then here's the detailed way of re-hosting Essbase:
Any Oracle EPM/Hyperion component currently configured is not only file system based but also has pointers stored internally in the EPM System Registry. That's not too simple to clean up. Here are the high level steps I'd go through to accomplish your task. Please pay close attention to the first one:
1 - Take a COLD system backup of the file system as well as the Shared Service (and all other if you can) databases/schemas. There will be no undoing the following steps.
2 - Inventory the existing Essbase applications, settings, file locations, and Essbase server usage (i.e. how many applications, their types and locations, are you using Planning or HPCM which have an Essbase backend, any scripts you have for automation which involve Essbase, any reporting data source pointers, etc.. To Essbase). The inventory is critical as you are basically adding a new Essbase server and need to ensure all apps and pointers are migrated.
3 - Confirm the existing and then decide on your new (To-Be State) Essbase instance naming convention and Essbase Cluster name. Typically the instance name is on the file system (i.e. Essbase1, Essbase2, epmsystem1, epmsystem2, etc...) under the Oracle\Middleware\user_projects folder, and the cluster name is normally EsbaseCluster-1... If the instance names rename the same you might save some time on the migration process of your scripts and apps however you will have confusion over what exactly to cleanup in the EPM System Registry once done. I like to use new names and deal with the script adjustments later as it's a good way to find things that might have been missed. I would also suggest tuning and keeping a separate copy of the EPM System Registry report (epmsys_registry.sh/.bat -> registry.html) and the EPM Registry topology report (epmsys_registry.sh/bat report deplooyment -> deployment.....html). These will be useful later on for before and after comparisons.
4 - If using a new set of cluster and instance names, go ahead and install the EPM software stack on the new server and then configure it with those new names. You now have a "second" Essbase server/instance available for use in Oracle EPM/Hyperion.
5 - Migrate your apps, settings, scripts, etc into that new Essbase instance/cluster. This sounds silly but you're basically treating this whole process like a migration to another environment. You can get all your security setup as well this way. Keep in mind that Planning/HPCM still might have points to the other Essbase instance so you'll have to move those/recreate the Essbase backends and then migrate objects. For classic Essbase apps, try using the EAS web console and migrating the apps to the new instance. That will bring over everything except Essbase data and Essbase security filters. Those you can port as you normally would (data export and load, etc...)
6 - Confirm everything works pointing to the new Essbase instance/cluster.
7 - Go for a beer/coffee (kidding it's a lot of work).
8 - Backup everything cold again, file systems and databases - this is a good stop gaap measure.
9 - Run the instance removal tool for the EPM System. it's a switch for the configtool.shg/bat JG_Gone has a GREAT introduction blog post on this tool: https://john-goodwin.blogspot.com/2013/05/11123-remove-epm-instance.html and remove the original Essbase instance. You of course can and should consult the 126.96.36.199 docs for latest info on usage. Be careful on this step. It will remove ALL products for the EPM System Registry that are installed and configured in that instance. So if you have epmsystem2 as your instance an dit has Essbase and Provider Services for example, both of those tools will be removed. This is why the inventory is essential above and checking it against your topology reports noted above will tell you if this is viable or not.
10 - Clean-up the EPM System Registry - This is a very tricky one but you basically need to go through and cleanup whatever is left from the old Essbase instances/cluster/server names. A bit tricky but if you read the 188.8.131.52 docs on the epmsys_registry.sh/bat tool it can be done: https://docs.oracle.com/cd/E57185_01/EPMDO/ch05.html Again - the database backup is critical to have before doing this. You'll be scanning the two .html reports you took above and removing any entries for the associated objects.
As you can see - this second process is not for the faint of heart - in essence as I mentioned above. you're basically building a new Essbase server and moving everything over to it then doing a manual/semi-automed cleanup of what's left. I've ben doing this work for 23 years and every time we have to do this type of infra work, precaution. backups and very careful inventorying are the best ways to avoid a nightmare scenario. if you haven't done this before, I STRONGLY encourage you to reach out to an expert/season infrastructure consulting. It's not a sales pitch, it's just the truth. Much cheaper upfront to pay someone who's done it than to have a long outage and wind up paying in the en anyway.
I hope this helps!!!!
Thank you Joe, I will try it in test environment and document it. But this is a good start. Really appreciated
Sounds good!!! Once you're good with this question please let us know by marking it answered so others in the community know you're all set.
Any other questions, please don't hesitate to ask!
I just want to give detail how we migrated the Essbase to new server using new host name and IP address. Joe response helped to plan it properly
Mount the shared mount to the new server and keep all directory intact as old server
Copy all files from old server to new server directory
Shut down the old server.
Register the new host name using the run epmsys_registry.bat|.sh updatehost oldHostName newHostName
Restart the admin service
Reconfigure the Essbase server only
Re-register the local host name for all components using each components ID. You can find the id from registry report and check in report for old host name. Any place you find old host then change it to new host name
Restart the services
Recreate all Essbase location alias
Copy the old Essbase config file to new server. It was over written when we reconfigure the Essbase server
From backend relational database changed the Essbase server name to the planning applications server connection
It seems everything is working.