Return to main navigation Page
Migration Tips and Considerations
The source and target sites must be on the same major
release version to migrate. Content may only be migrated across minor
releases within the same major release. Migration across major
releases cannot occur.
A "major release" is, for example, 2015 R1, while a "minor release" is, for example, 2015 R1 Update 1.
When upgrading to a new CPQ Cloud version, make sure
that the target and source sites are database copies of one another. In a
Development, Test, and Production environment setup, first upgrade your
test site (source), and then upgrade production (target).
- Only deployed data can be migrated. The
Migration Center shows the differences between the deployed data in both
sites. On the target site, migrated components are automatically
deployed. For example, if a Commerce Process is migrated from source to
target, the Process will be deployed on the target site after the
migration is finished.
- In order to migrate a Commerce Process, Allow Commerce Processes to be Cloned and Migrated must be set to Yes on the Commerce Settings page.
- A migration cannot be performed while a Rollback is in progress or while a Snapshot is being applied.
- Only one migration can be performed at a time.
- A Package cannot be imported or downloaded
while a migration is in progress, a Rollback is progress, or a Snapshot
is being applied.
- Data Columns can be deleted through
Migration. Deletion of a Data Column via Migration will have the
same effect on Transaction Manager Views and Reports on the target site
as if it were deleted in a Rollback.
A component created manually or through bulk services
on the source and target instances are not considered equivalent for
migration purposes, even if they have the same variable name.
For example, a Commerce Process on the source site
with the variable name "myProcess" is not equivalent to a Commerce
Process created manually on the target site with the same variable name.
The process "myProcess" should have been created on the target site
through migration, for it to be equivalent to the Process with the same
variable name on the source site.
Attempting a migration in this case will throw an
error. To proceed, delete the manually created component on the target
instance and then perform the migration.
- Items not available in the Migration Center
can be migrated by using Bulk Upload/Download. Some examples include
Accounts, Commerce Transactions, and Parts. See the topics Bulk Downloads and Bulk Uploads for more information.
Before migrating, be aware of dependencies. For example:
- Migrate Util Libraries used in Product Families and Commerce Processes before, or with, a Configuration or Commerce migration.
- When migrating, Util Libraries that are
referenced by selected Commerce Processes and Configuration Product
Families will be listed in the Dependencies dialog box. An
individual Util Library will be shown even if it was selected in the
main window at the start of migration. Select the Util Library in the dialog box even if it has already been selected in the main window.
- Upload Data Tables before migrating Util Libraries, Configuration, or Commerce.
- Migrate Product Definitions before Catalog data.
- Migrate Configuration data after migrating Catalogs.
- For newly created Commerce Processes, migrate the Commerce Process before migrating Documents.
- All Rollback data and all Snapshots are permanently deleted when upgrading to a major Release.
- Consistent with previous Rollback behavior, Transaction data will not be affected by a Rollback or Snapshot application.
- Consistent with previous Rollback behavior, Commerce Steps will not be deleted in a Rollback or Snapshot application.
- Only users with access to perform Migrations can also perform Rollbacks and Snapshot applications.
- If the user selects to have a Snapshot taken
when triggering a migration and that migration fails, the Snapshot will
still be created.
- Migration records cannot be deleted from the Migration Logs page if the “Undo” or “Revert to Snapshot” option is still available.
- The system will store data for up to 20
Rollbacks at a time. After a 21st successful migration, Rollback data
for the oldest migration will be permanently deleted.
- The system will store up to 10 Snapshots at a
time, whether or not they are Migration Snapshots or On Demand
Snapshots. After an 11th Snapshot of either kind, the oldest Snapshot
will be permanently deleted.
- Nominate one FullAccess user to perform
migrations. As of release 2014 R1, when a Migration fails the admin will
receive an email containing a log of the failed Migration stage and the
reason for failure.
- Establish a process for migration.
- Migrations should always be performed in
one direction. For example, always migrate from the test site to the
production site and not the other way around.
The URL of the source site can be set to auto-populate
when connecting to a source site from the target site target site. Open a
ticket on My Oracle Support to set the URL that should auto-populate.