Last week I was visiting a large computer processor manufacturer where we ended up in the building cafeteria which was packed with people eating apple pie. The pie was being served and offered for free because that day was “Pi Day” in celebration of the number Pi which is 3.1415926535897932 … etc.. The 3.14 translates into March 14 and this day is celebrated by math and computer enthusiasts and geeks everywhere. March 14 also happens to be Albert Einstein’s birthday.
However, this company took it a stage further by only starting to serve the pie at precisely 1:59:26 pm to match the next six digits of Pi (3.1415926. …).
I was impressed. This got me thinking about discussions I had earlier that day with another company regarding their BI 4.1 migration testing. It revolved around whether to test all the reports or just a sample of the reports to be migrated and the best way to test them.
There are a lot of changes between BusinessObjects XI 3.1 and BI 4.1 that could potentially affect queries and reports both from a layout and calculation perspective so it is advisable to validate all of them. This can be very time consuming if the report comparison is being performed manually and so tools to perform an electronic comparison could be employed to help speed up the process.
While some people may just check a sample set of reports they consider representative of all the reports or may just check certain totals on the reports, this is really only a partial validation. It is akin to accepting Pi as 3 whereas testing all the reports is more like accepting Pi as 3.142.
In addition, not all BusinessObjects reports are just one-dimensional static reports. Many have drill downs built into them, which should also be tested. Some are exported to other formats like PDF and Excel which should also be validated. There are also possibly universes, dashboards, explorer information spaces, schedules and publications. When you include all these additional aspects and content in your testing, you are much closer to seeing Pi as 3.14215926!
Of course, this should also encourage you to carefully audit your existing BusinessObjects repository, and only migrate what is actually in use and needs to be migrated. Auditing provides the best results when it has collected data over an extended period of time so be sure that you have it turned on. Look for content that has not been used for more than 12 months and question if it really needs to be migrated.
Also, check that users do not have local content on their desktops that needs to be migrated and request them to move it to the central repository.
Migration testing is often underestimated yet it is the most crucial phase to a successful migration. The good news is that if you plan and execute it properly, it will be as “easy as Pi!”