The previous post has discussed multiple ways of cloning environments, from on-prem Hyperion to cloud EPM to EPM automate. For more information, check the following post.
The screen-based clone environment interface surely provides flexibility and convenience. However, there are some caveats. I have seen folks cloning enrolments incorrectly or forgetting to update the URLs on the targeting side causes production issues. This post will mainly focus on the Pre-Clone and Post Clone Gotcha items.
First of all, the cloning environment feature is available for the following solutions:
- Planning
- FreeForm
- Financial Consolidation and Close
- Account Reconciliation
- Profitability and Cost
- Tax Reporting
- Narrative Reporting
For the detailed cloning feature, to perform the cloning feature, you have to have at least the Service Admin role. If migrating users and predefined roles are needed, then the Identity Domain Admin role is necessary as well.
To summarize:
The service Administrator can perform the following activities:
- Data Management
- Application Audit
- Job Console
- Stored Snapshots and Files
Service Administrator and Identity Domain Administrator can perform all the above plus:
- Users and Predefined Roles
Pre-Clone Considerations
When performing the cloning process, there are a few considerations we’d better keep in mind. I am listing these as much as I can. Hope these would help when using the cloning feature.
Legacy my services to OCI
Migrating from Cloud Classic to OCI, you must have the Service Admin and Identity Domain Administrator role to ensure that users and their roles are cloned to the OCI environment.
Single Sign On
When doing the Classic to OCI migration, you must reconfigure SSO.
Essbase version
The cloning process will upgrade the Essbase version in the target environment to match that of the source environment. However, it will not downgrade the Essbase version in the target environment to match that of the source. For example, if the source is Hybrid Essbase, and the target is a Non-Hybrid Essbase, the cloning process will upgrade the target to Hybrid Essbase.
Application version
Account Reconciliation, Enterprise Data Management Cloud, and Narrative Reporting do not support the cloning of an environment to an environment that is on a previous monthly update.
Source Artifact Snapshot
This cloning process uses the current “Artifact Snapshot”, created by the last daily maintenance. If you like to migrate the current stage of the application, rename the new backup file to “Artifact Snapshot” and of course rename the old snapshot file.
Target Artifact Snapshot
The cloning process does not delete existing snapshots or the files in the inbox and outbox of the target environment. If Artifact Snapshot exists in the target environment, the cloning process renames it as Artifact Snapshot_DATE_TIME.
Daily Maintenance
Initiate the cloning process after the scheduled daily maintenance of the source and target environments. Be sure to allow sufficient time for the process to complete.
Data Management stating table
Cloning of Data Management records may take a long time if the staging tables contain a very large number of records.
Data Management
Clone Data Management records only if both the source and target environments are on the same monthly update or the target environment is one update newer than the source environment.
Post-Clone Tasks
When the cloning process has been completed, don’t forget to update the URLs, logo, etc. URLs are surely one the critical ones. If you have certain REST API or Groovy rules that are using URLs, they may be still linking to the TEST environment.
Do check the following items making sure the migration/cloning process is truly done.
- Announcement
- Logo
- Connection — URLs and credentials
- Daily Maintenance time
- Groovy Rules
- Single Sign On
Hope this post completes the application cloning topic. See you next time.