Migrating Oracle On-Prem EPM Planning to Oracle EPM Planning Cloud

PARC Consulting has managed and performed the migration of Oracle’s EPM Planning from On-Premises to Cloud for quite a few customers. Based on our experiences, these are the key considerations and steps we have undertaken in what is usually a simple and straightforward process.

Inventory and Preparation

The first of our preparatory steps is to take a full inventory of the existing implementation, as our success depends upon knowing exactly what we need to replicate in the cloud. Important in this process are the following:

• Planning version: is the customer’s current on-prem version suitable for migration: 11.1.2.3 or 11.1.2.4 (and 11.2.x as long as Essbase 21c is not the back end).
• Security: How many users and access groups are there? Does the customer currently use SSO?
• Artifacts: Other than the typical Planning artifacts: Calculation Manager artifacts (if used), and Planning artifacts (Configuration, Essbase Data, Global Artifacts, Plan Type, Relational Data, and Security).
• Are there Essbase artifacts (Calculation and Report Scripts, Data Load Rules) that will require migration?
• Is the customer currently using on-premises FDMEE?
• Is the customer using EPMA?
• Because migration is a prime opportunity to purge old user accounts or application groups and retired forms, rules, etc., we seek to identify these items.
• Environment: Is this a single Planning application or are there multiple? Is standalone Essbase part of the picture?

The answer to this final question will drive which cloud products need to be in play and how many EPM Cloud instances will need to be available. For customers with a single Planning application and no standalone Essbase reporting cubes, this is the easiest of these possibilities. For all other environments with more complexity, multiple Planning, and Essbase reporting applications, more analysis, preparation, and planning are required. The remainder of this post will focus on the migration of a simple, on-premises Planning environment.

From a preparatory perspective, we determine the following:

• Does the Planning version need to be updated to a suitable version for migration? If so, we schedule this.
• What is the customer’s target migration date?
• Who will be performing the migration and data validations?
• Will there be a transition period during which the on-prem and cloud systems run in parallel?

For all the above, we ensure that the customer receives clear communication of what we are doing and why, and we make sure that all requirements and steps are fully understood, answering any questions that arise.

The Migration

First, we will typically do a quick dry run of the Planning artifact migration to a test cloud instance to ensure there are no problems, such as artifact naming or other issues that can be corrected at the source prior to migration. This is often done weeks before the actual migration to allow time to resolve any issues encountered.

During the actual migration the typical cadence follows this order:

• Migrate the Security Model: this includes the creation of the user, group, and role files, which are uploaded to the cloud identity environment and application. These files are used to create the users, assign roles in the cloud identity, and assign application groups in Planning’s Access Control system.
• Migrate the Planning artifacts, including application data.
• Migrate Essbase artifacts, including Calc Scripts (migrated to new business rules), Report scripts (migrated to Smart View Smart Queries), and Data Load Rules (migrated to file-based integrations in Planning Cloud’s “Data Exchange” module.
• If the customer is using FDMEE, this is also usually migrated to Data Exchange (formerly Cloud Data Management) in Planning.

Post Migration

After migration, we will want to validate those artifacts and data that have migrated successfully, then enter whatever transition period we determined during the inventory phase. PARC also provides a period of aftercare, during which we can provide knowledge transfer of new or changed procedures, answer questions, and further ensure that the migration was successful!