ec1

Post: Motio Cognos Migration – Easing the Upgrade Process

You know the drill: IBM announces a new version of their Business Intelligence tool, Cognos. You search the Cognos Blog-o-sphere and attend sneak-preview sessions for information on the newest release. It’s so shiny! Your reports will be so much happier in the latest and greatest Cognos version! But your excitement slowly slips away and is replaced by a nagging feeling in the back of your mind. Upgrading to the newest version of Cognos takes a lot of time, planning, and work.

There are so many circumstances that can affect how smoothly your upgrade goes. In a survey of over 100 cross-industry Cognos users, 37.1% said that managing the Cognos migration was their biggest challenge.

Motio Cognos Migration upgrade challenges

Project managers try to lower the level of uncertainty by designing project plans, which outline goals, budget, and deadlines. But they can’t totally eliminate the unknowns. And no amount of budget and time planning can prepare you to estimate the additional costs of unknown factors.

In the same survey, 31.4% of Cognos users admitted that automating the testing and validation was their biggest challenge of a Cognos upgrade. How do you ensure that your production content is working after the upgrade? Well, that requires ensuring your production content is working before the upgrade, and identifying what is not currently working. This is where testing before, during, and after the upgrade is necessary. But how do you gain complete visibility into content functionality and quality? And how do you automate the testing process? Okay, so maybe you don’t upgrade to the latest version of Cognos after all. Maybe you give up the promised new features for the comfortable existing ones.

But you know that technology is always evolving and improving. Staying stagnant will give your competitor the edge. You can’t have that!

Instead of fretting, try our 5 step methodology that includes using MotioCI software. This methodology is designed to help you set realistic expectations on how to plan, execute, and manage the upgrade process while MotioCI automates the painful tasks involved in upgrades.

Cognos Analytics Upgrade Methodology

Assess Your Current Production Environment

The technical paper begins with the importance of preparing and assessing your environment. Start off by determining what, specifically, you’d like to move. Think of the Cognos upgrade like moving to a new house. Toss out the junk you aren’t using (e.g. reports not used in over a year) and that broken lamp that is just not worth fixing (e.g. Cognos reports that no longer run.) And why would you move all 5 hammers when you only need one? (e.g. why move duplicate reports?)

Having a clutter-free Cognos content store can help you better predict the timeline for the upgrade process. In this first step, you will determine what you should move vs. what is clutter in your production environment. Now does getting to the latest version of Cognos already seem more manageable?

Setup for Scoping

Your next step is to version all objects in Production with MotioCI. Freezing production is ideal, but in some cases it is just not possible. With MotioCI in place, you have added protection with a “safety net” of your content so you can roll back to previous versions if need be.

You will then connect MotioCI to a sandbox and copy production here. The technical paper goes into more detail about the importance of using a sandbox that I won’t go into in this blog. You will use MotioCI to create an initial version of your production content in the sandbox and then setup and run test cases. This gives you a baseline of your production environment. You’ll run stability, output, and data validity tests, to know the state of your assets. The results of these tests will identify what needs further assessment.

Determine the Impact of Your Upgrade

MotioCI testing group and scoping labels

Once you have your first round of test results, this will help you establish what is in scope, out of scope, needs further attention, etc. This is where you gain control over your project’s timelines and the amount of work involved in your upgrade. You’ll label your assets as:

  • Out of scope content
  • Ready to upgrade- no issues detected
  • Broken, model change required
  • And so on.

And yes, you guessed it! The technical paper goes into greater detail on this step.

Repair

After you run the sandbox upgrade, run your test cases again so MotioCI can capture the results of the upgrade immediately.

This phase is where you will save a great deal of time and money on testing. You will use the automated testing available in MotioCI to test/repair/test/repair all of your assets until they are either out of scope or ready to upgrade.

It’s important to repair any problems MotioCI may have identified while upgrading to the new version of Cognos. Instead of the guess & check method (“let me fix the issue, did it work? No. Does changing that work? Still no.”) MotioCI’s reporting feature is very valuable in gauging the number of failing or passing test cases over time, so that you can easily monitor their progress.

Upgrade and Go Live

The final step is to execute a secured “go live.” This usually happens during off business hours. Copy the MotioCI test cases from the sandbox to the live environment, and ensure that a backup of the content store has been made. You will save some additional time by using MotioCI’s deployment capabilities to easily move the “Repaired” label content from your Sandbox to Live environments. You will also rerun the test cases here, assess the results and determine when to go live.

So, maybe the upgrade process just requires a different, more agile approach to be successful. It requires a thoughtful, but not daunting, process to ensure that your Cognos upgrades are planned and executed more efficiently. Use MotioCI in the process from start to finish. MotioCI will help you:

  • Plan the appropriate scope to determine workload
  • Assess the impact of the upgrade
  • Repair problems and ensure they stay repaired
  • Execute a secure “go live”

Want to learn more? Read our Improving IBM Cognos Upgrades Technical Paper to learn the more in-depth attributes of each step.

Scroll to Top
As the BI space evolves, organizations must take into account the bottom line of amassing analytics assets.
The more assets you have, the greater the cost to your business. There are the hard costs of keeping redundant assets, i.e., cloud or server capacity. Accumulating multiple versions of the same visualization not only takes up space, but BI vendors are moving to capacity pricing. Companies now pay more if you have more dashboards, apps, and reports. Earlier, we spoke about dependencies. Keeping redundant assets increases the number of dependencies and therefore the complexity. This comes with a price tag.
The implications of asset failures differ, and the business’s repercussions can be minimal or drastic.
Different industries have distinct regulatory requirements to meet. The impact may be minimal if a report for an end-of-year close has a mislabeled column that the sales or marketing department uses, On the other hand, if a healthcare or financial report does not meet the needs of a HIPPA or SOX compliance report, the company and its C-level suite may face severe penalties and reputational damage. Another example is a report that is shared externally. During an update of the report specs, the low-level security was incorrectly applied, which caused people to have access to personal information.
The complexity of assets influences their likelihood of encountering issues.
The last thing a business wants is for a report or app to fail at a crucial moment. If you know the report is complex and has a lot of dependencies, then the probability of failure caused by IT changes is high. That means a change request should be taken into account. Dependency graphs become important. If it is a straightforward sales report that tells notes by salesperson by account, any changes made do not have the same impact on the report, even if it fails. BI operations should treat these reports differently during change.
Not all reports and dashboards fail the same; some reports may lag, definitions might change, or data accuracy and relevance could wane. Understanding these variations aids in better risk anticipation.

Marketing uses several reports for its campaigns – standard analytic assets often delivered through marketing tools. Finance has very complex reports converted from Excel to BI tools while incorporating different consolidation rules. The marketing reports have a different failure mode than the financial reports. They, therefore, need to be managed differently.

It’s time for the company’s monthly business review. The marketing department proceeds to report on leads acquired per salesperson. Unfortunately, half the team has left the organization, and the data fails to load accurately. While this is an inconvenience for the marketing group, it isn’t detrimental to the business. However, a failure in financial reporting for a human resource consulting firm with 1000s contractors that contains critical and complex calculations about sickness, fees, hours, etc, has major implications and needs to be managed differently.

Acknowledging that assets transition through distinct phases allows for effective management decisions at each stage. As new visualizations are released, the information leads to broad use and adoption.
Think back to the start of the pandemic. COVID dashboards were quickly put together and released to the business, showing pertinent information: how the virus spreads, demographics affected the business and risks, etc. At the time, it was relevant and served its purpose. As we moved past the pandemic, COVID-specific information became obsolete, and reporting is integrated into regular HR reporting.
Reports and dashboards are crafted to deliver valuable insights for stakeholders. Over time, though, the worth of assets changes.
When a company opens its first store in a certain area, there are many elements it needs to understand – other stores in the area, traffic patterns, pricing of products, what products to sell, etc. Once the store is operational for some time, specifics are not as important, and it can adopt the standard reporting. The tailor-made analytic assets become irrelevant and no longer add value to the store manager.