Oracle Hyperion migration features and hiccups

Migrating to Oracle Hyperion got easier with version, but there are some issues such as with Essbase Studio that should be fixed in future versions.

Oracle Hyperion includes new tools that will ease migration, cutting down on the number of steps needed in many cases. However, there are still some issues, such as with Essbase Studio, that should be fixed in future versions.

After several weeks of working with the Oracle Hyperion release, I can safely say that, overall, Oracle's development team did a nice job. Hyperion Financial Management (HFM), Planning, Essbase, Shared Services and Financial Reports all migrate smoothly. Thus far, I haven't tried to migrate any edge products -- for example, Interactive Reporting -- but the fundamental components definitely work.

New Oracle Hyperion migration features

A nice surprise in the release is a new utility called hssmigrate. In previous releases, a utility called CSSImportExport did the Shared Services security migration. Using this tool, you had to export security from Shared Services, create an XML or CSV file, update the file manually and then use the file to import security into the target environment. It sounds easy enough, but that the utility is Java-based, which means it is case-sensitive.

Using development and production environments as an example, users had to export security from development, create the XML or CSV file, transfer it to production, modify the file manually to reflect the products and server names and then import security from the file. It was a manually intensive process.

Additionally, the case-sensitive aspect of the utility had the potential to cause headaches. Since there are no restrictions on naming conventions for external providers, people tend to name each one differently. There are no constraints in place to make sure that the external provider name in the source environment (development) matches the target environment (production). For a successful migration, the external provider names had to match.

For example, say you wanted to migrate security from development to production. The provider name in Development is TOPDOWN (all caps). For a successful migration, you would have to know the provider name in development and, accordingly, create the same provider name, using the exact spelling and case, in production. The problem is that oftentimes more than one person does the installation of the development and production environments. Therefore, the provider names can end up out of sync. And at this point, you can't complete the migration. The only solution is to correct the provider name in one of the environments.

Oracle recognized this problem and eliminated it with the hssmigrate utility. The utility creates an hssmigratedata.zip file on the source environment's Shared Services machine. You can then transfer the hssmigratedata.zip file to the target environment's Shared Services machine, launch the configurator, select Import Data from Earlier Release and you're done. The new utility doesn't care what the provider name is. It imports security to the existing External Provider regardless. This saves a lot of time and energy and eliminates the previous issues with server names and product suffixes, among other things.

Another nice new feature is the Planning application migration wizard. The preliminary steps to migrate a Planning application are still the same. However, the interface to do the migration has changed. What used to be a button on the Planning login page is now a nicer and more intuitive wizard on the Planning Administration page. The difference is that you go through Workspace to navigate to the Planning Administration page. Once on the Planning Administration page, you select the Migration Wizard tab, where you can select the application you want to migrate.

Everyone logs in through Workspace these days, so to go through the Planning Web interface to find the Migrate button was not very intuitive. There is no new functionality with this process; in, you click the Migration Wizard tab and then select the application, and the wizard will upgrade it. The new process is much more intuitive.

Oracle Hyperion migration drawbacks

What didn’t work so well in is the Essbase Studio migration. The installation guide provided a step-by-step process, but it didn’t work, and my first attempt at the migration was unsuccessful.

The migration of the Essbase applications also had a versioning issue. The traditional way to migrate Essbase applications is through Essbase Administration Services (EAS). It is as simple as logging in, connecting to the source Essbase server and connecting to the target Essbase server. You then launch the migration wizard, point to the source Essbase application, create the Essbase application on the target Essbase server, follow a few steps, and the application is migrated.

With, the process still works the same way for Block Storage Option (BSO) cubes, but it throws an error message for Aggregate Storage Option (ASO) cubes. Behind the scenes, though, it appears that the migration does bring the metadata over, and the ASO cube migrated successfully. This was confirmed by doing a post-migration high-level test. However, I have not done any low-level testing, so I cannot speak to whether the migration was complete. The other thing about the Essbase application migration is that the documented process is long and drawn out. After going through all the steps, you still end up with files that need to be transferred from the source Essbase server to the target Essbase server.

Final thoughts

Future Oracle Hyperion releases should fix the Essbase Studio migration. That said, since it is a very new application, there are not a lot of people using Essbase Studio. The previous version is buggy and the migration doesn't work, but given the small user base, fixing this is probably not a priority for Oracle at this time. The other nice fix would be the ASO cube issue. Even with these two items, though, overall migration eases the pain of the process.

Eldred Smikle is the technical services manager for TopDown Consulting. He has more than 10 years experience working with Oracle Hyperion Enterprise applications. Follow Eldred on Twitter @TopDownInc.

Dig Deeper on Oracle Hyperion