BICS Lift and Shift from OBIEE

Recently I led a comprehensive analysis and POC for lift and shift of on-premises 11g to Oracle BI Cloud Service (BICS). The lift and shift approach is gaining popularity as it offers a hybrid BI Cloud without having to worry about data security and recreating metadata in the cloud. BICS can leverage the on-premises repository and databases to give users access to extensive BI Cloud functionality. Comparing pro and cons of lift and shift will help organizations determine the right approach.

POC Outcome:

1. BICS offers end users an enhanced analytics experience leveraging the latest Oracle BI platform including Data Visualization and Mashups against their own external data.
2. This hybrid approach of BICS with an on-prem data warehouse lowers infrastructure needs for servers, clustering, patching and upgrades.
3. On-going maintenance is needed for the administration of users and application roles.
4. Oracle’s future strategy is on Cloud for new feature releases and are available automatically to end users.
5. Report performance in BICS was comparable to on-prem report run times.

Guide to Oracle Cloud: 5 Steps to Ensure a Successful Move to the Cloud

Explore key considerations, integrating the cloud with legacy applications and challenges of current cloud implementations.

Get the Guide

Challenges:
You will likely encounter some of these issues depending on your on-prem setup, I have shared some approaches to resolve them.

1. In order to connect BICS to an on-prem database via Remote Data Connector (RDC) we needed to establish a secure connection between BICS and the on-prem Oracle WebLogic Server.
   1. One-time setup required coordination between Oracle Support and the Network Admin team.
   2. This is no longer an issue for future dashboard migrations.
2. If you want to use the same Application Roles as on-prem, there are steps you will need to take based on the current setup.
   1. Naming convention of OBIEE Application Roles, such as BI Author, is not supported on BICS (no spaces permitted).
   2. Resolution required renaming and reconfiguring app roles as part of the migration process.
   3. Requires configuring data filters (row-level data security) for application roles.
   4. The new application roles need to be maintained only in BICS RPD version.
   5. This is a one-time setup of the Application Roles during the migration.
3. Catalog, Dashboard, and Reports Migration is straightforward for the most part, however, the catalog permission didn’t migrate properly.
   1. Manually assign catalog permission for dashboards and reports after migration as they don’t get migrated to BICS.
4. If your reports have drilldowns (Links to Detail Reports) you have to apply a workaround to get them working.
   1. Adjust the catalog references to comply with BICS – the default folder path is different in BICS (/Shared vs. /Company_Shared). This can be modified using XML search and replace in catalog manager.
   2. Drilldown links worked as expected after the adjustment was applied.
5. BICS to on-prem Essbase is currently not supported, but Oracle has confirmed it is on their roadmap.

Maintenance:
BICS, like any other application, requires some ongoing maintenance.  IT will need to allocate time for support and maintenance.

1. Independent version control of the BICS repository (RPD)
   1.  Separate repositories (RPD) are version controlled for BICS vs OBIEE 11g
2. Administer Users and Application Roles
   1. Role Management: Update, Add, or Remove
   2. Application Role Management: Assign Roles to Application Roles
   3. User Administration: Manage user assignment to Roles (bulk assignment supported via file upload)
   4. User removal is manual process, bulk load option is not available at this time
3. Dual Maintenance of Subject Areas, Dashboards, and Reports may be required if they co-exist in both on-prem and BICS
   1. If the requirement is to maintain the same dashboards and reports in both on-prem and BICS

Recommendations:
My recommendations are based on ease of setup, reduced maintenance, and issues encountered. The idea is to have BICS lift and shift up and running in a few weeks in order to take advantage of the new features and functionality.

1. Migrating from OBIEE 11g to BICS directly is recommended only when subject areas and reports are to be enabled on BICS alone and disabled in OBIEE on-prem.
2. Recommended approach is to do a gradual migration of different user groups/subject areas to BICS.
3. One-time setup and configuration effort is required for releasing additional subject areas.
4. New content for migrated user groups is created only on BICS (no dual maintenance for BICS migrated subject areas/reports)
5. If you want to mirror subject areas and reports in both OBIEE on-prem & BICS, I recommend you upgrade your on-prem OBIEE to 12c. Upgrading to OBIEE 12c avoids challenges with ongoing maintenance of mirrored content.
   1. Repository version will be the same between OBIEE 12c and BICS.
   2. Web catalog, dashboards, and reports can be migrated using a single (.bar) file.
   3. OBIEE 12c upgrade includes renaming application roles to adhere to the OBIEE 12c/BICS naming convention. This avoids dual maintenance of separate lists of application roles.

Overall, it’s a great approach for OBIEE on-prem users to transition some of the reporting needs to cloud to leverage new features, Data visualization, reduce licensing, and infrastructure costs.