In Part 1 of this blog post series on Enterprise Planning and Budgeting Cloud Service (EPBCS) deployment considerations, I covered key topics such as change management, education and training as well as upgrades and maintenance. I’ll pick up where I left off and share my thoughts on support and migrations.
Support
In the event an error or defect is encountered, a “Provide Feedback” option is available within the EPBCS service. Submitting feedback provides Oracle Support technicians with environment details at the time of error. Then, customers proceed to create a service request in the “Cloud Support” subsite of support.oracle.com.
In addition to Oracle software support, many customers opt for application-level support with third-party vendors. The contracts come with a variety of terms and service level agreements. For example, Perficient’s managed service offering, SupportNet, offers:
- Flexible service-level agreements
- Dedicated customer service manager
- Help desk tickets for defects/issues
- Scheduled support hours for custom development
- Monthly or quarterly sizing options
- Variable length contracts
Regardless of support provider, it’s crucial to begin knowledge transfer early in the project. The post implementation support team is the final pillar of change management, ensuring business continuity and user satisfaction after the EPBCS application is put into service.
Migrations
Customers converting from on-premises Hyperion Planning will be happy to know that that EPBCS is an evolution of Hyperion Planning, not a complete revolution. Life Cycle Manager extracts from the current on-premises application and can accelerate the conversion to the cloud. That said, migrations are not a push-button process.
One key difference is that cloud customers are limited to one application per instance. Customers that have several planning applications will need to consider consolidating applications or licensing multiple cloud instances and integrating them.
Another key difference is that not all artifacts are supported for migration. Items like Essbase business rules, substitution variables, and data load rules can’t be imported to EPBCS.
For customers with a single Planning application, it should be straightforward to map to the “standard” plan types. If the on-premises application also has the on premises modules, customers will want to consult with implementation partners to adequately plan and execute the conversion. Oracle also publishes guidance on data, metadata, and feature mapping between the two editions.
The simplest case of all is migrating a finished EPBCS application across cloud instances – DEV to PROD, for example. For this, EPBCS customers will use the “Migration” cluster. This leads to a screen where you select from five application components: Planning/Data Management/Calculation Manager/Groups and/Reporting. These create snapshots from the source cloud instance which can be transferred to the target cloud instance and imported.
