What are the Best Practices for Migrating Setup Data from Test to Production in Oracle Fusion SaaS Cloud implementation?

Prepare Environments for Migration

When exporting and importing, the Oracle Fusion Applications Cloud revision of both source and target environments must be the same.

Ensure that your test and production environments are at the same revision level before you begin the export or import.

Some setup data may not be supported for automatic migration through export and import. Review the Setup Task Lists and Tasks report from the Offerings page to identify the setup tasks that don't have associated setup services. Setup data of these tasks require you to migrate them manually to production using an alternative method. Always ensure that an exact copy of the setup data is migrated from source to target. Refrain from entering data manually in the target environment, unless indicated by the import process.

Manage Setup Data in Test Environment

Use the test environment for both maintaining and verifying setup data, follow these steps.

  1. Enter and verify setup data in the test environment.
  2. After setup data passes verification, export from the test and import into the production environment.
  3. If the test environment requires refreshing with setup data from the production environment, use production to test (P2T) refresh cloud service.

Additional Points to Consider

Here are some additional points to consider while exporting and importing setup data.

  1. Ensure that all setup data is thoroughly tested and verified before you import into the production environment. Similarly, if export and import processes aren't available for any setup data and you enter it manually into the production environment, ensure that you created and verified the same data in your gold and test environments first before entering it into the production environment. The data in both the environments must be an exact copy.
  2. If you enter any setup data manually into the source environment (Gold or Test as applicable), as well as into the target environment (Test or Production as applicable), and later use the export and import processes to migrate the same data, the import process might fail. This happens because those records are rarely an exact duplicate of each other in both the environments. As a result, row key validation of those records fail during import.
  3. When exporting setup data using an implementation project, export only one offering at a time. For more details, refer to the topic Setup Data Export and Import Using Implementation Project.
  4. Use the scope value to limit the volume of exported setup data. Scope is particularly useful when you're migrating only the incremental changes to setup data after you completed the initial deployment of an offering to the production environment.
  5. Source control the exported configuration package files to keep a history of setup changes that were applied to the production environment.
  6. Consider running comparison of the setup data in the configuration package file with that in the production environment before starting the import process. This lets you review how import changes the production data and help you to avoid making unwanted changes in production.
  7. Don't ignore the tasks you must perform before and after import. You must migrate their data manually. Otherwise, setup data in production remains incomplete, causing errors during transaction processing.
  8. If you're implementing multiple offerings at the same time and importing their setup data into production concurrently, then you must import those offerings in the same sequence as specified in the following section to avoid errors related to data dependencies.

No comments

Ask a question
1000 characters left