Best Practices for Migration

Here are some of the recommended best practices that you must follow to migrate your configuration sets.

General Recommendations

Recommendation	Details
Don't cancel or retry the migration process.	The migration process can take some time. So, even if the process seems to be slow, don’t cancel or retry. Allow the process to complete without any interruptions.
Test all application changes in the source environment.	You must test all the application changes made in the source environment before starting with the migration process.
Check before you restore your environment after migration.	You can't restore your environment to an earlier configuration if the environment is upgraded after your previous migration. But if a new import is submitted in the upgraded instance, then the most recent import can be reversed.
Run the Metadata Manager in the source environment using Application Composer.	After an upgrade to the source and target environments, if you want to migrate your application changes, run the Metadata Manager in Application Composer on only the source environment to support delta migration.
Check data security privileges as they aren't automatically revoked in the target environment.	During migration, the data security privileges aren't automatically revoked in the target environment. For example, say a specific privilege is granted in the target environment, but the corresponding privilege doesn't exist in the source environment. During import, the privilege in the target environment isn't automatically revoked. To address this issue manually, add such a privilege to the source environment and revoke it. The revoke action is picked up as a configuration instance during the migration import process and applied to the target environment.
Initiate migration export and import tasks only from the mainline metadata.	You can initiate migration export and import tasks only from the mainline metadata. You can't initiate a migration if you're in an active sandbox.
You can't access certain reports or dashboard pages during an upload or restore activity.	While an upload or restore activity processes Presentation Services changes, these things can happen: Reports that were submitted by Oracle Enterprise Scheduler to Oracle Analytics Publisher and were scheduled to execute during the process might fail. The Reports and Analytics pane might not be displayed. Oracle Analytics Publisher reports might not be displayed on Oracle Business Intelligence Presentation Services analyses or dashboard pages. Users might not be able to access these Oracle Transactional Business Intelligence features: Oracle Business Intelligence Answers Oracle Business Intelligence Delivers Business Intelligence Composer Oracle Business Intelligence Interactive Dashboards
Don't restore your environment to an earlier configuration.	When you restore your environment to an earlier configuration, you lose all personalizations you made after the previous migration.
Never modify the metadata extract.	You can't modify the metadata extract. You can migrate metadata from one instance to another.
Do a full migration, if your source and target environments aren't synchronized.	If your source and target environments aren't synchronized, you must do a full migration to synchronize them. When you do a full migration, you move all your changes from the source to the target environment. However, if you made changes to the target environment, then these changes might be overwritten when you do a full migration.
Never make changes in the target or production environment while applying configurations.	You must never make changes in the target or production environment while applying configurations. Note: If you make changes in the production environment in emergencies, you must make the same changes in the test environment. Making the changes in the test environment ensures that these changes are included in the subsequent configuration migration. But remember, in Application Composer, you must not create, edit, or delete an object in the production environment. If you do so, you need to ask your help desk to log a service request for refreshing the production-to-test data so that you can avoid any migration issues.
Never create custom objects directly in the target environment.	To avoid metadata inconsistencies while migrating security changes using the Functional Setup Manager, you must not create custom objects directly in the target environment.
Make application changes at the user level or the job role level during the migration process.	During the migration process, you can make application changes at the user level or the job role level because personalizations made at these levels aren't migrated.
Avoid changing security policies directly in the target environment.	After migrating security changes from the source to the target environment, avoid changing security policies directly in the target environment. For example, if you want to change the end date for a security grant, don’t change it in the target environment. Instead, make such changes in the source environment and migrate them to the target environment.
Make sure the source and the target environments are on the same release and same patch level and have the same database version.	For secure import, make sure the source and the target environments are on the same release and same patch level and have the same database version. Avoid making any changes directly in the target environment. Instead, make changes in the source environment and migrate these changes to the target environment. However, if unavoidable, you can make only these application changes in the target environment manually: Server scripts Field changes made using Page Composer, such as adding and removing fields, and setting a required field. Label changes You must not make any other application changes manually in the target environment. Note: The application changes that you create manually are overwritten by the changes made during subsequent migration from source to a target environment.

Recommendations for Source and Target Environments

Recommendation	Details
Plan your migration.	Plan to import your migration sets during periods of low system usage or low user activity.
Alert users about your migration.	Alert users about the planned import by adding a banner on the home page using the Page Composer tool.
Avoid making any application changes in the Site layer.	Don't make any application changes using application composer or page composer in the Site layer.
Avoid making any changes in the source and the target environments during export or import.	During export or import, you must not make any changes in the source or target instance.
Avoid publishing your sandbox during the import.	During import, don’t publish your sandbox. If you publish your sandbox during this period, the import process might fail.
Make sure you create the reports and reference them to subject areas that were created in the source environment.	You can create reports directly in the target environment. However, make sure you create the reports and reference them to the subject areas that were created in the source environment. Don't create subject areas directly in the target environment.
Migrating your application changes might result in changes to fields that are marked as required in the application.	As a result of the migration, there might be changes to fields that are marked as required in the application. If you get errors while entering data for business objects, make sure to sign out and sign back in after the import.
From the target environment, make sure you delete the flexfield metadata that were deleted from the source environment.	The flexfield metadata that are deleted from the source aren't automatically deleted from the target during the migration process. So, to make sure the source and the target have the same flexfield metadata, you must manually delete the flexfield metadata from the target. Otherwise, you get merge conflicts in the merge log. For example, suppose you created a flexfield segment with the segA segment code in the source environment and assigned it to a Character column. This setup is then migrated to a target environment. Now, in the source environment, you change the column assigned to the segment to a Number column. As the change is not allowed directly on the setup UI, you delete the segA segment code and recreate it with the same segA segment code using a Number column. When this data is migrated, you get merge conflicts in the merge log as the same segA segment with a Character column already exists in the target environment.
Lookup values for lookup fields aren't overwritten during the migration import.	The lookup values for lookup fields that exist in both source and target aren't overwritten during the migration import. The values from the source are added to the target and they coexist for the same field. For example, the Status field in its source environment has values, Open and Closed. In the target environment, this field has values, Yes and No. After the import, the Status field in the target environment has values, Open, Closed, Yes, and No. Note: The lookup values that are deleted from the source aren't automatically deleted from the target during the migration process. So to make sure the source and the target have the same lookup values, you must manually delete the lookup values from the target.
Make sure you use either migration or setup data migration for all lookup migrations.	You can migrate lookups with both migration and setup data migration. However, once you use one of these methods, you must use the same method for all subsequent lookup migrations. Don't use both methods to migrate lookups between the same set of environments.
Don’t publish your application changes directly in the target environment.	To make sure changes aren't published in the target environment, set the Control Publish Sandbox Action in Production Environment profile option (FND_ALLOW_PUBLISH_SANDBOX) to No in the target environment.

Recommendations About When to Not Migrate

Recommendation	Details
While a quarterly update is in progress in the production environment, don’t migrate your application changes that were done using the Application Composer.	Quarterly updates take two weeks to complete on your provisioned (non-production and production) environments, during which time the environments are on different updates and patch levels.

The following figure represents the timeline and the recommended safe period for performing migrations using Configuration Set.

Recommendations for Faster Migration

Recommendation	Details
Always perform a delta migration.	This reduces the size of the migration set that must be migrated from source to target and can shave off a significant amount of the time it takes to perform a full migration.
Complete any preparatory work and prerequisites.	To expedite your configuration set migration, perform all preparatory work ahead of time, such as exports and imports. Note: Migrating your configurations and Setup and Maintenance capabilities, such as exports and imports are two separate and independent processes and should not be confused as one full migration.
Select only the required optional modules to reduce migration failures.	For faster migration, if there are no application changes in specific components, exclude them from migration. For example, if there are no application changes related to BI or Analytics, exclude the BI component for migration.
Exclude custom Business Intelligence reports from migration by backing them up outside the Custom folder.	This creates a smaller-sized archive file for an easy and successful migration to the target environment.
Don't migrate flexfield configurations related to business intelligence, if you don’t need them.	If you don't need to migrate flexfield configurations related to business intelligence, set the Business Intelligence Extender in Configuration Set Migration Disabled (FND_CSM_BI_EXTENDER_DISABLE) profile option to Yes. Setting this profile option to Yes makes the migration process faster. The default value for this profile option is No. You can find this profile option in the Manage Administrator Profile Values task in the Setup and Maintenance work area.