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 Fusion Cloud Enterprise Data Management.
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 Artifact 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 5: Refreshing a Test Environment with Production Data.
When using granular templates, include any dependent metadata objects required by the selected artifacts. Preview the template import before importing it into the target environment to identify missing dependencies.

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

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.

Recommendation

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 granular roles. See Export Artifacts in Administering Migration
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

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.

Recommendation

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: Deploying an Application Update

Scenario

Your development team has completed the next phase of work on an application. The changes include new viewpoints, hierarchy changes, properties, validations, subscriptions, and other related metadata that should be promoted together into production.

Recommendation

Use an application template.

Application templates are appropriate when the changes represent a logical update to an application or dimension and should be migrated together. Because the template includes the related application metadata, it provides a straightforward way to promote coordinated changes between environments.

See Updating an Existing Artifact using a Template for considerations.

Scenario 4: Migrating Individual Metadata Changes

Scenario

You created several new custom validations that will be reused by multiple applications, updated a global connection, and modified an extract. No application metadata or hierarchy changes need to be migrated.

Recommendation

Use a granular template.

Granular templates enable you to select individual metadata objects across supported artifact types and package them into a single template file. This approach is useful for small, targeted migrations because it transfers only the selected artifacts instead of an entire application or dimension. Before importing the template into the target environment, preview the import to identify any missing dependencies that must also be migrated.

See Exporting Selected Metadata Objects to a Template.

Scenario 5: Refreshing a Test Environment with Production Data

Scenario

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.

Recommendation

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.