Top 10 OBIEE Upgrade Strategies and considerations

In this post, I list top OBIEE upgrade strategies and consideration, not necessarily in any specific order, as the order of significance would depend upon individual implementation scenarios.

Oracle offers multiple starting points for OBIEE upgrade. The strategy that would be best applicable to a situation is dependent upon multiple factors. Following the considerations that any organization must review before selecting an upgrade strategy:

1. What is the current version of OBIEE / Siebel Analytics - Some upgrades are performed in-place while others are fresh install. The method applicable will be dependent upon starting and target versions, and also on known issues on upgrading between these versions. An in-place upgrade is best when the upgrade is performed of relatively recent prior version. This would typically mean less issue, less testing, and easier upgrade. However when the upgrade has to be made on a very old version of OBIEE, it would require out of place upgrade. Even if technically it was possible, it makes sense to upgrade on a sandbox, and to find out how the upgrade process responds in terms of issues or ease of upgrade. However in case of an in-place upgrade, typically if dev environment is upgraded to newer version, its very difficult to go back to older version. So even in that case, my personal recommendation is to perform an out of place upgrade on a sandbox and make sure the process goes smoothly and any issue encountered is manageable / non show stoppers, before  doing an in-place upgrade of development.   

2. For some cases, you may have to make multiple hops for the upgrade. For example if someone is still on Siebel Analytics version 7 (or earlier), they will have to go to version 10.1.3.4.1 and then finally upgrade to 11g. Obviously this poses significant upgrade risks in terms of number of issue and unknown problems that could creep up. Best process is to keep doing incremental upgrade every year or every other year and avoid such problems down the road.


3. When do you expect to go live with new version (considering time required for testing, and commitment from business to verify the upgrade along with other factors) - Duration of upgrade projects vary and depend on volume of reports / dashboards that are in production. It also depends how many components are being upgraded and factors like:
1. Do you have BIAPPS in OBIEE?
2. How many modules of BI Apps are implemented?
3. Is BIAPPS being upgraded too?
4. Is Informatica / ODI / ETL tool being upgraded too?
5. Is database platform being upgraded too. ?
6. Finally, is source system getting upgraded too?
More the number of components, higher is the complexity of the upgrade. Some upgrade decisions are made by companies to be able to stay supported by Oracle, because Oracle stops supporting older versions after a period of time.


4. When can we commit on getting a code freeze in the current version of OBIEE - this should be calculated backward from the expected go live date - This is one of the toughest piece to pull off for a larger upgrade. Often OBIEE upgrade ends up being an in-flight upgrade. Meaning, changes are made to current production version of OBIEE while the upgrade is being done to a newer version. In such cases, upgrade team has to make sure any additions / changes to current version are brought over to upgraded version before the go live. There are two ways of doing this:
1. Rebuild additions in the new version
2. Re-migrate OBIEE in a sand box, and copy over the changes.

The choice of path to bring additions will also depend on where the changes are? RPD, Reports, Dashboards, Scheduler, BIP etc? In no case you want to allow significant changes to be made to older version once upgrade process has kicked in. Significant 'addition' of completely new models although might still be ok, which can be easily copied over. Finally, going for a re-upgrade with all changes would be the last option, as this would mean doing a complete sanity check all over again, and a headache for upgrade team as well as the end user testers.

5. Do you have BI Publisher content in current installation ? If yes, then how many reports are there in BIP?  - BIP has had significant architecture changes from 10g to 11g. Some of which would require rebuilding the code.

6. Do you have iBots/Agents in current install? If yes, then how many?  - Again this might mean re scheduling of jobs, as database structures over the years have changed. The decision is a factor of difference between new and older versions.

7. Do you want to upgrade all code at once (big-bang) or in parts (this might mean two OBIEE environments in production running in parallel till everything is brought over). - Although not recommended, but sometime due to the volume of code partial upgrade might be the only option. The separation could be made between independent departments or subject areas, which don’t use conformed dimensions. Only caveat to this approach would be if there are users who access all areas, they might have to login to different servers for reports.

8. How will the security model be in old vs new version? Will it remain the same or there will be changes made to it?  - Security implementation has significantly changed between 10g and 11g. This is a one time setup, but may mean redoing the security - especially LDAP based security in 10g, which was RPD based, is not weblogic based in 11g. Although data level security may not require any changes, as its often external table driven. But if data level security was applied using RPD group filters, that might have to be redone.

9. Instance strategy and MUD environments - while upgrading you might want to revisit number of instances required 'during' the upgrade as well as final list of instances. During upgrade typically you would have additional sandbox instances. The number of sandboxes might depend on number of components that are being upgraded. For example, if you are upgrading BI Apps as well as underlying database, you might want to keep two instances to better utilize development resources. One team would work on platform upgrade of OBIEE, while the other could perform testing against new database. A key consideration here is for the MUD sandbox. You want to make sure that MUD sandbox where code is tested before being pushed to development is the same environment as the dev/test/prod. If prod OBIEE is on a non windows based machine then it might mean having two boxes for MUD, one for client tools (if you don’t want developers to have client tools on their machines) and second the BI Server on a unix box.


10. Bug fixes available in newer version - decision to upgrade could also be based on the fact that newer version has a bug fix or a functionality that is required by the organization. This is more important if the issue is in production, and needs a solution. Other factors like Essbase integration of OBIEE makes a strong case for some organizations to upgrade. 

In addition to above considerations, while upgrading, you might want to take advantage of new features of the target version, for example mobile platform support in 11g, like iPads i.e. iOS mobile devices. Android fans no need to be broken hearted yet, as OBIEE has plans for android support in its pipeline. They plan to have their charts and graphs delivered in  HTML5 language, which will slowly transition to support in Android I believe at some point in 2014 or 2015.