There may be multiple political/managerial reasons behind a decision to move from Hyperion's Essbase to Microsoft's Analysis Services – not least of which might be the recent purchase of Hyperion by Oracle.

Whatever the reason, from a developer's viewpoint, moving a set of multi-dimensional databases from one engine to another is non-trivial. What are your options?

At the risk of teaching my grandmother to suck eggs, moving a cube isn't really about the data, it's about the meta data. The raw data is typically held in a relational database somewhere and the cube is refreshed from that data source every night.

In a migration project we have to move the cube structure, which is essentially no more than a metadata description of how the users think about the data and how they want to see and analyse it.

It takes a great deal of effort to understand what users want: many hours are spent in listening and discussion to extract subtleties of meaning. This is followed by further long hours encapsulating this into the measures, dimensions, and hierarchies that will form the cube design, along with any data manipulations that require the use of built-in and custom-built functions. It is all of this that needs to be ported between engines.

And there is more. Essbase and Analysis Services differ in their capabilities. A five-year-old Essbase cube will have been built within the hardware and software constraints of the time. These may well have placed huge restrictions on the fundamental cube design, restricting factors like granularity and dimensional complexity. In the current version of Analysis Services, on modern hardware, these constraints may no longer exist. In an ideal world, your migration should take advantage of the improvements made over the last five years.

Porting a simple cube with few measures and dimensions doesn't present much of a problem, but most cubes in commerce are relatively complex and a manual conversion can easily take three to four person-months per cube. One reason it takes so long is that a person with Essbase skills does not typically possess Analysis Services skills as well. While good practice in cube design is a transferable skill, Essbase developers will probably have to learn the idiosyncrasies of Analysis Services (both good and bad) and discover the new features that can be used to advantage when porting cubes.

CubePort

ExoLogic has developed a package called CubePort which does a great deal of this work for you. The company has undertaken many migrations and has distilled the huge amount of knowledge gained from those into its porting tool.

ExoLogic makes it easy for potential buyers to see what the product could do for them: a free download of CubePort will run against Hyperion's sample cubes and the output cubes can be generated in either Analysis Services 2000 or 2005. To buy the product costs $15,000 per cube, for which sum you can run the cube through the CubePort software as many times as required. If you're dealing with many cubes, ExoLogic will also offer volume pricing. The price compares well to the cost of three/four months of developer time - and you should also be able to move the project along much more rapidly.

For potential customers who like what they see from the free download, ExoLogic can offer a means of showing the migration of your own Essbase cube into an Analysis Services cube. This is an astute move: seeing the transformation of your own familiar cube has the potential to be very compelling and although you don't get the software to play with, you do see a walk-through of the CubePort translation process.

Any downsides? Well, at the time of writing, CubePort has no support for the UDM (Unified Dimensional Model) that forms part of Analysis Services 2005. ExoLogic is investigating the possibility of providing UDM support at a later date, and if successful this will be a considerable feat.

CubePort's interface is that of a wizard which, at its most basic, needs only to ask the user to identify the cube to translate and to state where the translated cube should be saved. In fact, the wizard is rather more inquiring, its questions mostly aimed at determining the style of the new cube design. For instance, there is a step to determine the hierarchy of a Time dimension which can be tweaked to include levels from years to seconds, with eight possible levels in between.

Being able to run CubePort against a cube multiple times gives developers the opportunity to try design variations by selecting options presented by the wizard. Translation of a cube may be repeated so long as the "metadata stays structurally consistent" and if only "minor changes" are made to the source cube. Using CubePort for the migration of multiple cubes has the added benefit of consistency between the different translations. Cube design is almost as much of an art as it is a science, and during manual migrations, different developers may choose different approaches with the outcome of inconsistent cube design. Using a tool such as CubePort guarantees much greater consistency for far less effort.

I can't, of course, tell whether CubePort is suitable for your business' cubes – if the cubes are minimalist, you probably don't need it – but if you're faced with migrating even the average business cube, investing in a free download and some experimentation time could well be worthwhile. ®