We had the opportunity to try the Clone Environment feature in Cloud EPM Planning recently. When this feature was first announced, I was pretty excited. It sounded like it would make migrations of Test to Prod and vice versa much easier, no longer would it be necessary to either download/upload snapshots or write EPM Automate scripts. I had heard about issues when it was first introduced a few months ago, but it seems that subsequent updates have got it working now.
Keep in mind, this is a full migration of the application using the most recent Artifact Snapshot. There is no option to use a different snapshot or be selective in which artifacts to migrate, it is everything. And the target environment is recreated as part of the process, so anything that had been there will get deleted. If you need more flexibility in what to migrate, you’ll need to use other methods like copySnapshotFromInstance.
From the home page, go to Tools > Clone Environment.
Enter the target URL, username, and password.
The username has to have at a minimum the Service Administrator role. If the user provisioning is to be migrated, the Domain Administrator role is also required. Checking the box to include Users and Predefined Roles will migrate the roles that have been assigned in My Services. This is useful if you intend for the target environment to have the identical access as the source. If access groups are being utilized for dimension and other access control (and you should be using groups), then migrating the provisioning ensures all the users assigned in a group are correctly set up. However, often times you don’t want the same users in target and source, in which case leave the box unchecked. You will then have to update any provisioning of users in My Services and add to groups in the target after migration.
Notice the Snapshot name in the above screenshot. The most recent Artifact Snapshot is listed. If there have been changes in the source application since the last time the snapshot was created, you will need to run the EPM Automate command runDailyMaintenance. This will create a new Artifact Snapshot.
We needed a new snapshot, so the following script was run.
We were then ready to run Clone Environment.
We kept track of our progress.
Uh oh, something went wrong.
Clicking on the Failed hyperlink opens the details and we can see what caused the failure. We had an invalid form in the source application. This same error would have occurred in a traditional migration as well.
A note about this failure. The migration was actually successful, except for this one form. This is similar to migration errors with Users or User Preferences. If we had not checked the box to migrate provisioning, it’s likely we would have had errors for each of the users in the source that were not provisioned already in the target. But the application still migrates. It would be helpful if Oracle would call it “Partial Migration with Errors” or something like that instead of “Failure”.
Even though the application migrated except for one form, we decided to correct the form in the source and re-run the Clone Environment.
Success! As we can see from the start time and end times in the status section, the cloning took only 11 minutes for our application. And that includes the recreate of the target environment. Doing each of these steps the old way most certainly would have taken longer. In general, Clone Environment is a useful feature when migration of the entire application is needed. When more selective artifact migration is needed, create snapshots of those artifacts and move the file between environments with manual downloads and uploads or EPM Automate copySnapshotFromInstance.
As always, happy EPM’ng!
Random EPM Notes 
One thought on “Migration with Clone Environment”