With the addition of Oracle Analytics Cloud (OAC), Oracle Cloud now has a PaaS solution that can manage all your data analytics requirements within one tool. It is a scalable, reliable, and secure cloud service with extensive analytics capabilities at a lower cost when compared to OBIEE. OAC offers analytics and reporting, data visualizations, data modeling, self-service analytics, big data analytics, machine learning, and predictive analytics under a single license.
Additionally, there is a dynamic mobile app to stay in touch with your reports and insights. So it comes as no surprise that companies are considering migrating their analytics solutions from earlier business intelligence tools like on-premise OBIEE and cloud-based Oracle Business intelligence Cloud Service (BICS) to OAC, to take advantage of the advanced features and capabilities it brings to the table. In this blog post, we attempt to explain a high-level approach for Oracle BICS to OAC migration and the key things to consider during the process.
The Three Phases of Oracle BICS to OAC Migration
Compared to OBIEE, migrating services from BICS is almost identical with some additional steps. The migration tasks are categorized into three phases: Preparing for Migration, Migrating the Service and Final Configurations and Cleanups. They could be better explained with the image given below:
Now let us take a look at the three phases in detail.
1. Preparing for Migration
Before we begin with the migration, the foremost thing that you need to confirm is the capacity of the OAC instance. The instance should be able to handle the load of service that you are planning to migrate. To evaluate the compatibility of the OAC instance, compare the current configurations – size (users), shape, and location with the BICS environment. If additional capacity is required, consider scaling up.
After the initial assessments, the next step is to migrate users and roles. Migrating the users beforehand reduces the overheads in the later stages. To migrate users, generate a CSV export of the users in the BICS environment and import them to Oracle Identity Cloud Service (IDCS). The next thing to do is to migrate roles. Unfortunately, there are no easy export-import steps available here. The export file needs to be created manually by referring roles and custom roles tab in BICS before importing it as groups in the target environment. By importing the manually created file, you’ve completed the migration of users and roles. Now provide the appropriate OAC application roles for the migrated entities.
The next important step in this phase is Data Migration or Data Connectivity. The approach can vary based on the current location of your data. If the data is in Oracle Database on Oracle Cloud Infrastructure Classic, you need to migrate it to a database on Oracle Cloud Infrastructure. Then after you migrate your BICS instance, data models need to be updated to point to the new database. For the rest of the scenarios, there arises no need for migration of the data. After migrating the BICS instance, one only needs to update the data models to point to one’s data. But in the case of on-prem databases, there is an additional requirement of configuring the Data Gateway and whitelisting the IP addresses associated with OAC Instance.
Once the above-mentioned tasks have been completed, you are ready to begin the next phase.
2.Migrating the Service
Refer to the following diagram to further understand the steps of migration.
Before proceeding further, ensure to take a backup of the OAC environment. If you come across any issues during the migration, you could roll back the instance to the previous state. Now, to create the snapshot of the service you want to migrate, go to the BICS console and select the new snapshot option under snapshot and models. Enter a name for the snapshot and save it. Choose the newly created snapshot and download it to your local machine. The snapshot file downloads as an archive file in bar format.
Now let’s move to the target environment, OAC, and upload the bar file (snapshot archive). Once the upload is complete, restore the snapshot by choosing the restore method. It is very important to choose the right snapshot option for your use-case. Choose the snapshot method accordingly. It’ll start restoring the snapshot and wait a few minutes for the process to complete. In some scenarios, the content migration is over by this step, but few things are not covered in the migrated content. If you uploaded any data files (Excel, CSV, etc…), map plugins, or custom visual extensions in the source environment, they need to migrate separately. There is a migration utility in OAC to take care of this task.
By now, you’ve successfully migrated all the contents from BICS to OAC. The next step is to activate the data connections. In BICS, data connections are created via a data modeler or RPD. So based on the type of connection, the activation steps can vary. In the data modeler, if you have used the default connection in BICS, it should be recreated in OAC. To activate other data modeler connections, one needs to simply edit and save them. In the case of RPD, reconfigure the connection details inside the data model file using the developer tool client. Now make sure that all the connections are activated and the data is syncing.
The final step in this phase is to verify and configure the service settings in the OAC environment. First, check whether the users and application roles are configured and assigned correctly. A tenancy prefix will be there in the ‘search crawl users’ after migration. However, it isn’t required in OAC. So, edit ‘search crawl users’ to remove the unwanted prefix. Then the following steps are optional depending on your environment. Go to the OAC console and update these settings one by one as required – Extensions, Maps, System settings, Mail Server, Safe Domain, and Virus Scanner.
3. Final Configurations and Cleanups
Once the first two phases have been completed, the service is migrated from BICS to OAC. Now, the remaining steps are some cleanups and final configuration updates. If you’re having deliveries scheduled in BICS, they’ll be disabled by default in OAC, and you need to activate those one-by-one manually.
In this phase, test the migrated instance end-to-end and ensure that everything is working as expected. Check data sets, data connections, data models, dashboards and analyses, deliveries, user accessibility, and security, etc. If everything is working as expected and the OAC instance is production-ready, you could proceed with the cleanup tasks. Clean up is mainly required in the source environment. You could delete migrated contents from BICS and associated resources to reduce unnecessary costs and free up space. Perform thorough auditing to identify the resources that can be removed without affecting any other services and delete them.
Key Points to Consider while Migrating Oracle BICS Instance to OAC
There are certain essential processes to consider during the migration process. They are as follows:
- Update the header of the exported user details file as per the requirements in OAC.
- Include valid roles only while creating the user groups file for migrating.
- Choose the restore snapshot options carefully. The ‘Replace Everything’ option resets the entire target environment while the ‘Replace Snapshot Contents’ keeps everything intact except the snapshot contents. The custom option offers more flexibility for choosing the content to import.
Typical Implementation Time Frame for Oracle BICS to OAC Migration
The image below shows the implementation time frame for the migration process.
**The tentative timeline is for a mid-size organization with around 20-25 medium complex reports in BICS and datasets requiring migration or on-premise gateway configuration.
The Business Intelligence Tool landscape has evolved rapidly with the introduction of cloud-based self-service analytics tools. These tools offer a platform to handle your basic or advanced analytics needs with a single platform. For the organizations in the Oracle environment, Oracle Analytics Cloud provides such a flexible platform to analyze your data. In conclusion, since the older versions of OBIEE are going out of support and features of BICS are very limited, it is only right that organizations consider migrating to the cost-effective OAC.
Senior Software Engineer, RapidValue