Art of BI: Migrating Oracle BI to the Cloud – Lift & Shift Considerations
Christian Screen | | August 15, 2017
When you have an on-premises installation of Oracle Business Intelligence, the most obvious way of getting to the cloud is lift and shift — that is, taking your existing configurations and moving them as-is to the new platform. Here’s a look at what you should think about before beginning this migration.
Lift and Shift Tasks
While it’s conceptually simple and even straightforward, completing lift and shift will take some time. There are four major tasks, including:
1. Lifting and shifting application roles
2. Lifting and shifting the repository,
3. Lifting and shifting the web catalog
4. Doing repository ADF and consistency checks.
You can find the full procedure for each of those tasks in this blog from Oracle.
But before you head over to read that blog and start executing those procedures, you need to take a minute to step back and think more carefully about your migration plan.
Things to Consider Before You Lift and Shift
To start, are you technically ready to migrate? Lift and shift requires starting from Oracle BI version 184.108.40.206 or later, so you may need to upgrade your on-premises installation to a newer version of Oracle Business Intelligence before beginning the migration. That’s a project in itself, though you can get help from a BI consulting firm like Datavail that’s done hundreds of upgrades.
You’ll also want to make sure your BI applications are working the way you want them on-premises before making the shift to cloud. Any ADF and consistency check issues need to be fixed locally before the repository can be migrated.
Another reason to make sure everything is working right locally before moving to cloud is that if you shift a configuration that’s causing you problems already, you’ll struggle with a learning curve in cloud while you try to make things work. It’ll also be harder to tell where the root of any problem is that you might encounter originally began. It may seem like moving to the cloud and then making changes or fixing issues will get you to a working Oracle BI Cloud installation faster, but it’s likely to just end up complicating your migration.
Lastly, think through your security plan before you migrate. There are pre-defined roles that control user access to data. You should understand how these roles relate to the roles within your organization so you can grant users the appropriate security. It’s important to be clear on this so you don’t unintentionally grant users more privileges than they need and introduce security risks.
Don’t Start in Production
Before you execute any transition steps, make sure you have an up-to-date snapshot of your installation and understand how to restore and fall back to that in case you run into any unexpected problems. Know how you’ll validate and test your migration. Document your verification process; you’ll want to validate for both completeness (everything you expected to migrate was moved successfully) and correctness (everything you migrated works as expected).
It’s best to start by migrating a QA environment before tackling production; this will let you get familiar with Oracle BI cloud and discover any omissions or complexities with your plan without impacting production.
By paying attention to these considerations, your lift and shift to Oracle BI Cloud can run smoothly and successfully.
As an Oracle Platinum Partner, Datavail is one of Oracle’s most experienced partners for implementing Oracle Business Intelligence (OBIEE) and the Oracle BI Analytic Applications. Our proven methodology can help your project succeed, regardless of stage. Whether you’re looking for short-term or long-term managed services support, we can make the positive difference in getting an ROI on your software investments.
For additional resources please download my white paper: Migrating Oracle BI Applications to the Cloud.
EPM applications help measure the business performance. This post will help you choose the best EPM solutions for your organization’s needs and objectives.
Imagine there are over one hundred logins in the source server and you need to migrate them all over to the destination server. Wouldn’t it be awesome if we could automate the process by generating the scripts for the required tasks?