If you are unable to create a new account, please email support@bspsoftware.com

 

News:

MetaManager - Administrative Tools for IBM Cognos
Pricing starting at $2,100
Download Now    Learn More

Main Menu

Migration from Business Objects XI.R2 to Cognos 10.2.1

Started by bhanu.samas, 20 Nov 2014 11:57:14 AM

Previous topic - Next topic

bhanu.samas

Hi,
Are there any tools or is it possible to migrate universes and reports from Business Objects to Cognos with out developing/designing model in Cognos Framework Manager?

Thank you,

Regards,
Bhanu.

cognostechie

Framework Manager has an in-built feature to import Universe model. That being said, it will defeat the purpose of migration because then FM will be the same as Universe. A good idea would be to import Universe and then re-design it using FM features so that you can take advantage of Cognos features. The reports will have to be re-written using the package published from FM.

bhanu.samas

Thanks,
I'm working on a project we are trying to migrate around 400 canned reports and 700 ad-hoc reports from BO to Cognos. One way we are thinking is to redesign in framework to develop reports. Other way we are trying to explore if there is any tool which can migrate all the universes to framework packages or some sort of thing. It is a bit old application, there are around 105 universes in BO and I don't why they had to create than many universes and we are thinking to clean all that stuff and design one package, ideally. Could you please provide your input on this?

Thank you,

Regards,
Bhanu.

cognostechie

I am working on a similar project. I am re-designing but Cognos to Cognos, not BO to Cognos. We currently have about 40 packages with data split in those packages so the business cannot get the complete picture from any of those packages. The data is also wrong. There are about 1700 reports most of which are copies of each other with just different filters. My guess is that they created different universes because they could not figure out how to relate data sets of different granularities together and still get the correct data in reports.

You might want to start thinking in terms of what should be the design rather than what it is now and how to migrate it, then consider whether the effort required to migrate and re-design will be less or re-design and build from scratch will be less. Look at the source tables, how many data sets, modules, tables, joins etc and whether or not you can put it together in one package. FM will let you put it in one package which is what I am doing. You will need to be very familiar with how FM generates queries in case of multiple granularities etc. My reports will be reduced from 1700 to around 175 using advanced cognos security and macros.

Whatever you decide the ultimate result is that if you create many packages then the solution will not be as successful as having less packages. The more you can put in one package the better the quality and reliability.

bhanu.samas

Thanks Cognostechie,
Yeah, Its better to keep all in one package (Ideally). Some of the guys in my organization are working in the direction of lift and shift tools from IBM to migrate model from BO to Cognos. I suspect that even if IBM has any tools for lift and shift it might end up in creating 101 packages and I don't think it can group all in 1 package without having business knowledge and what table is what. Once again thanks for your input.

Regards,
Bhanu.

Lynn

Excellent advice from Cognostechie. I'd further add that moving away from IT developed formal reports over to a user self service approach is worth considering. In that scenario a user would ideally have a small number of packages pertaining to specific business subject areas from which to choose for their analysis and reporting.

I think a lot of people look back on work they've done previously and see ways to improve or refine if given the chance to do it again as well as the need to enhance beyond the original requirements due to changing business or even good alterations based on technology and features not available at the time....so if you follow that line of reasoning then lift and shift is a lost opportunity to address any of those things.