Hyperion upgrade creates issues with migrating Essbase data

We upgraded Hyperion from 9.3.1 to 9.3.3 and then finally to 11.1.2.1. Now we need to REFRESH the Essbase data and the Level 0 data  from prod 9.3.1 to 11.1.2.1.

We ran the Migration Utility in 9.3.3 and loaded 0 level data. Ran Calc All. We were surprised to find out that the .pag files and .ind did not match the size in prod. Since we did not receive any errors, we are assuming that 9.3.3 caused the 25% file increase. Not sure about running the Restructure. We used it on one database and the size of the .pag files almost doubled. How do we migrate Essbase data and Zero level data from 9.3.3 to 11.1.2.1?

I read your article on hssmigrate, which was great, but still have questions on Essbase data. The 9.3.3 Server and 11.1.2.1 Server are on separate boxes, so I don’t see 9.3.3 in the console when I log on to 11.2.3.1.  Both are registered with different versions of Shared Services.  Can 9.3.3 still be placed in the easconsole for 11.1.2.1?

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 11.1.2.1, 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.

If you are asking how to migrate Essbase data, then the easiest way to is to do a full export from the current environment, which creates atext file. You then import that text file to the new environment via “load data”. Depending on the size of the database(s) being exported the text files can get quite large.

However, if you are asking why there was a difference in number/size of the .IND and .PAG files when comparing pre/post upgrade, it seems like this can easily be attributed to a clean data load of Level-0 data in the upgraded version. Unless you did a “dense restructure” prior to upgrading, the old  .IND and .PAG files may have space reserved for data that has been cleared or for members that have been removed.