You’ve heard it since the advent of Oracle Planning and Budgeting Cloud Service (PBCS). Migrating your Hyperion Planning environment to the cloud means no initial upfront cost for hardware or software, less IT involvement, and no annual maintenance costs. It’s an attractive offer — but, for many, migrating to the cloud is an unknown process.
The migration may not be as tasking as you think, and it gives you a great opportunity to clean your environment and streamline your processes. In this blog post, we’ll go over what needs to be consolidated and streamlined versus what stays the same during your migration. (For a deeper dive into cloud migration best practices, you can jump straight to the video.)
What version of Planning do you need for a straightforward migration?
Fortunately, using Oracle Life Cycle Management (LCM) to migrate your applications should make the process fairly simple — if your on-prem environment is 11.1.2.1 or newer. For previous versions, the migration won’t be supported by Oracle, but you still have options:
- The recommended path is upgrading to a newer version of Planning and then migrating to the cloud.
- If you don’t have it in your budget to pay for an upgrade, the other option is to rebuild in the cloud using artifacts from your previous environment. For the most part, you can extract all your dimensionality and send it to cloud with relative ease. However, migrating your forms will take quite a bit more work.
Migrating plan types
When you start looking at migrating your plan types, you have the opportunity to cleanse your environment and processes. There’s a series of questions you’ll need to ask yourself before migrating your plan types:
- If you have multiple Planning applications, can you combine them into one PBCS pod?
- How many total BSO and ASO plan types do you have?
- PBCS has three BSO plan types and three ASO plan types. If you currently have too many, do you need to convert or consolidate your BSO to ASO, or vice versa?
You also need to look at the dimensionality of your plan types. If they have an overlap in members, you can consolidate those plan types. If not, you need to consider how you can fit your plan types into PBCS.
Calculations
If you use calculation manager, LCM can take all your calculations and migrate them. The calculation manager is available in the cloud and you can make modifications to your calculations once they are in the cloud.
If you use the Business Rules Server, things become a little more complex. In this situation, you’ll need to take all your existing rules and convert them, which may require a lot of manual efforts.
Calculation scripts don’t exist in PBCS, so you must do a manual conversion to business rules since the scripts will not import via LCM. This can be as simple as copying and pasting your calculation scripts to business rules. This presents another opportunity to cleanse your environment. Since administrators have the ability to make calculation scripts quickly, they typically have a lot of calculation scripts that were only used for a specific instant and never revisited.
Load rules
Load rules also don’t exist in PBCS. This leaves you with three options to choose from:
- You can use data management in PBCS, which is the cloud version of FDMEE. However, you’ll only be able to work with flat files in data management.
- You can also use FDMEE on-prem, which has the ability to load data directly to the cloud.
- Your last option is the native Essbase format, which is not necessarily the best way, but it is the fastest.
Report scripts
Report scripts aren’t all necessary and allow you to once again streamline your processes since they do not exist in the cloud. Usually, report scripts are used for things like getting data off an ASO cube with no export command. So how can you do that now that report scripts no longer exist? You have several options:
- The first way is to use native PBCS utilities, which don’t automate your process but will extract your data quickly.
- You can also use business rules where you have a data export command. This isn’t a process documented by Oracle, but it does allow you to export data. Doing it this way puts your data into the data management outbox.
- Your last option is to use cloud-based data management or on-prem FDMEE, which will produce a flash file or go into a table with your ODI scripts.
Automation
About 70-80 percent of your migration to the cloud will be spent on automation. Unless you have a lot of consolidating to do, very little of your time will be spent on plan types or forms since LCM expedites the process.
Automating your metadata requires the use of a new tool — EPM Automate. This tool mimics the ability of the outload load utility that on-prem users are familiar with, but adds some additional functionality like the ability to upload files. There are several other features separate from typical planning functions, since the EPM Automate tool was created to span the entire EPM cloud stack.
To automate your data processes, there’s a little more work involved than the typical load rule. In the cloud, you must go into data management, define what your flat file looks like in an input format, and then apply your rules. Though it’s a longer process, you end up with more flexibility, automation, and visibility. Load rules typically get buried, which can create an issue with admin turnover. In the cloud, you gain visibility and have a single avenue to importing data.
For more details about migrating your Hyperion Planning environment to the cloud, watch the webinar replay!
