Migration Scenario Examples

Best Practices

Before you transfer applications from a source to a target environment, ensure that both environments are on the same version of Oracle Enterprise Data Management Cloud.
When you have two environments that you are transferring applications between, ensure that you are making changes (for example, application registration changes or property creation) in only one of the environments and then transferring them to the other. Do not make changes in both the source and target environments and then try to merge them.
For example, do not create a property in both environments and then try to migrate changes to that property from one environment to the other using a template. This will cause the system to create a second version of that property, as the source and target objects will not have the same ID. See Updating an Existing Application or Dimension using a Template.
To ensure that your objects have the same IDs in both environments, you can use a migration snapshot to resynchronize them. See Scenario 4: Refreshing a Test Environment with Production Data.

Scenario 1: Moving Applications from a Test Environment to Production in Preparation to Go Live

In this scenario, you have been developing and testing in your test environment and you are ready to transfer your applications to your production environment in preparation to go live.

For this scenario, you can use a template to migration the application metadata. This ensures that you bring your applications over, but not any audit history or test data from your test environment that may not be relevant to your production environment.

Then, if you also want to transfer the users and groups from your source environment you could use a migration snapshot for users and groups only to transfer them, and if you do want to bring over the data from the source system you can use exports and imports (or extracts and loads) from your source to your target environment. For example, here is a common approach for this scenario:

Ensure that the target environment doesn't have any existing applications, data, or audit history in it already.

Tip:
You can accomplish this by recreating the service in your target environment. See Recreating the Service.
Ensure that the users and groups are set up in the target environment.

Tip:
If the users and groups in your target environment are the same or very similar to the users in your source environment, you can use migration to export the Groups and Membership component only and import it to your target environment. This brings over your users and groups, as well as any assigned application roles. See Export Artifacts in Administering Migration for Oracle Enterprise Performance Management Cloud
Use a template to transfer the applications in your source environment that you want to bring to your production environment. You can transfer multiple applications using a single template file. See Working with Templates.
If you want to bring the data from your test environment over as well, use the following to transfer data from your source to your target environment:
- Exports and imports (for bound data only).
- Extracts and viewpoint loads (for bound and unbound data, as well as unbound dimensions and hierarchies).
Perform any additional manual post-transfer tasks for objects and settings that do not get transferred with templates. These can include:
- Application and global connection parameters such as locations, identity names, user names, and passwords.
- Top nodes in node sets
- Top node filters in subscriptions
See Template Objects and Settings for more information.

Scenario 2: Updating a Production Environment with a New Application from a Test Environment

In this scenario, you have created a new application in your test environment, performed all of your acceptance testing to your satisfaction, and you are ready to load it into your production environment to roll it out to users.

For this scenario, you would most likely use a template. Templates enable you to move a single application and merge it into an environment that contains other applications. Keep in mind, however, that only the application metadata is transferred. If the application in your source environment also contains data that you want to transfer to your target environment, you will have to export and import (bound data only) or extract and load (bound and unbound data).

Scenario 3: Incrementally Updating a Production Application with Changes from a Test Environment

In this scenario, you have an application in production that you want to make changes to. You have made the changes in a test environment (for example, let's say you've modified some custom validations, created a new extract, and changed the formula for a derived property) and you want to migrate those changes to your production application.

For this scenario, you would use a template to incrementally update your production application with changes from your test environment. See Updating an Existing Application or Dimension using a Template for considerations.

Scenario 4: Refreshing a Test Environment with Production Data

When you have a production environment for your day-to-day activities and a test environment where you test new applications or new features, it can be useful to refresh your test environment periodically with information from your production environment in order to keep the test environment in sync.

For this scenario, it is most often helpful to use migration snapshots. This enables you to do a complete refresh of your test environment with all applications, settings, data, users, and groups from your production environment.

Note:

The migration snapshot of your production environment can also be used on a user acceptance training (UAT) site or as a backup on a disaster recovery site.