Migrating from Cognos to Microsoft BI – revisited

My original post on migrating from Cognos to Microsoft BI has consistently been the most popular on this blog pretty much since I wrote it, so I’ve decided to come back to the topic now that 2008R2 is out in the field and 2011 (Denali) is on the horizon. I also have some more detail and insights, especially thanks to the many comments made on the original post.

One thing to take away is that both stacks have their passionate supporters and detractors, but on high level functionality there really isn’t a coherent technical argument for either product. It still remains a case of what is appropriate for your business requirements. Both product sets meet most requirements. From the comments on my original post, it’s clear that some people’s understanding of the MS BI stack is not always great, and often still seems rooted in what was offered in SQL2000 (a decade ago!).  The biggest gripe from the Cognos away team was the lack of a Framework Manager equivalent in the SQL Server stack. I think this is fair comment – however BISM in Denali I think is going to bop that one on the head pretty swiftly.

So if there’s no real technological lever to drive you one way or the other, what factors should be considered when choosing between the two stacks?

Cost

There’s no escaping the fact that IBM/Cognos licencing costs are significantly higher than Microsoft’s, and their licencing structures are more complex. When people talk to me about migration, cost is always the #1 factor. I recently was talking to a BI Architect who had just joined a major company who cited a licence cost for their Cognos Reporting Server which would have funded a SharePoint and SSRS installation and a significant number of report builds – all with no loss in functionality. I’m not sure he was best pleased with the use of that investment.

The reality is most Enterprises and SME’s have licencing agreements that cover all MS BI tools to some extent anyway – SQL Server, SharePoint and Office all usually have a presence somewhere and IT can squeeze more value out of these existing licences. Remember that every dollar spent on licencing is a dollar less available for actually delivering BI.

Implementation costs tend to be cheaper too – Microsoft skilled staff are cheaper and more numerous, so you are less likely to be stuck trying to find a capable resource and they will cost you less when you do.

End User Adoption

In the coming world of Self Service BI, the end user is king. More often than not, Excel is the throne upon which they sit. I’m sure I don’t need to point out which vendor offers the tightest Excel integration. With SharePoint 2010, Excel and its new friend PowerPivot become a powerful offering (see my earlier post on PowerPivot) that genuinely breaks the ties between IT and the business. People love to work in Excel and Microsoft are always going to have this advantage when it comes to selling the solution to consumers. SharePoint becomes the icing on the cake, with rich collaboration features making BI much more interactive between users. 

The IBM/Cognos suite still seems to be driven by a IT delivered philosophy – and the unfamiliar tools and interfaces make it difficult for the business users and Cognos to make friends. To be fair, when they do become friends it all works out rather well, but that initial hurdle still has to be overcome.

Innovation Shortfall

This is probably the most contentious argument, seeing as Microsoft have a long history of “buying” innovation into their BI stack, but the reality is that IBM/Cognos has stagnated and is in a position where it will have to play some significant catch-up. Hindered by a product line with a lot of overlap, sooner or later IBM/Cognos are going to have to choose to innovate and advance some products and can others – which will cost goodwill in some customers. But until they do, they are going to lag further and further behind.

Final thoughts

Since my original post, my position hasn’t moved a great deal. The Microsoft suite simply offers better value and lower long term TCO. With the ever increasing SharePoint and Excel integration end users are going to favour Microsoft’s offerings. Finally, unless Cognos really raise their game soon, the technical argument which is currently evenly balanced will soon tilt in Microsoft’s favour – then the decision becomes too easy.

5 thoughts on “Migrating from Cognos to Microsoft BI – revisited

  1. Hi – since your original posts, has the Microsoft ‘gap’ around Cognos Planning been filled? What would you look at for forecasting data capture? Sharepoint/InfoPath, Excel?

  2. Hi Gerald. There’s nothing on the SQl2012 roadmap that I know of, so if it does return, it’s a long way off. I’d look to 3rd party apps such as Olap Office (I know the guy who runs it, he’s very into budgeting / forecasting) to fill the gap – these tend to live in Excel.

    As for data capture, bit of an aside but look at Business Connectivity Servies (BCS) in SharePoint 2010 – allows for direct writes to database objects.

    Hope that helps!

  3. How VERY exciting. I have over the last decade years often pushed my chair back, puffed on my pipe and thought “what the world REALLY needs is a pivot table you can write to”. I shall be evaluating that in earnest over the next few days.

    Thanks for the BCS tip as well.

  4. I am trying to create a Power Point presentation to try an convince the Business why IT wants to move to a Microsoft Enterprise Architecture and use Microsoft BI tools (including BI Stack) vs the current Cognos that they utilize because they are resisting change, althought the direction of IT is Microsoft Enterprise Architecture. If anyone has any documentation or power point presentations on this I would really appreciate it if you would post them!!! Thanks, Earlene Stewart

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>