Migrate an Oracle Content Management Instance

If you have an Oracle Content Management instance running on Oracle Cloud Infrastructure (OCI) Gen 1 or OCI Classic, Oracle recommends that you migrate the instance to the new native OCI environment—Gen 2 OCI (that is, using the Oracle Cloud Console to manage service instances). This will ensure that you’ll enjoy the benefits and advances of Oracle’s cloud platform in the future. Or you might want to move an instance running on Gen 2 OCI to a different region.

Note:

If your instance is running on legacy Cloud Infrastructure using a non-metered subscription, follow the steps in Migrate an Oracle Content Management Instance from Legacy Cloud Infrastructure instead.

To initiate migration, you’ll need to perform a few steps prior to migration and work with Oracle Support to schedule the migration.

  1. Create a new instance of Oracle Content Management on OCI with the Oracle Cloud Console. This will be the target instance your data will be migrated to. Do NOT use this instance until migration has been completed.
  2. Migrate your users and groups using the appropriate methods. If you're migrating from OCI Classic, you don't need to migrate your groups.

    Oracle is in the process of updating Oracle Cloud Infrastructure (OCI) regions to switch from Identity Cloud Service (IDCS) to Identity and Access Management (IAM) identity domains. All new Oracle Cloud accounts will automatically use IAM identity domains. Depending on whether your old instance (the source) and your new instance (the target) use IAM identity domains or not, you'll use different methods to migrate your users.

    Exporting Users and Groups from Your Old Source Instance

    Make sure to preserve the user names so that roles and permissions can be migrated appropriately as part of the migration process. In the exported CSV file, it's the "User Name" entry.

    Importing Users and Groups to Your New Target Instance

  3. Prepare for migration by collecting information you'll need for your service request and creating a list of any integrations you have for steps you'll need to take after migration.
  4. Submit a migration service request, and confirm the date and time of your migration.
  5. Watch the progress of the migration. Your service request will be updated as your migration progresses, and when it's done, you'll be asked to verify that your new instance is working as expected.
  6. Finalize the migration by completing any steps necessary to migrate any integrations that your instance has with other services or applications.
  7. Communicate the change to your users.

Prepare for Migration

You need to gather some information to prepare for migration:

  • Make a note of the URL of the new instance (the target) you created, to include it in your migration request.
  • Make a note the URL of your old instance (the source), to include it in your migration request.
  • Make an inventory of all integrations that your old instance has with any other services or applications, either directly or through REST API calls. If there are any such integrations, then you’ll need to take some actions after the migration.

Submit a Migration Request

When you’re ready for your migration, you must submit a migration request to get the process started:

  1. Sign in to Oracle Cloud Support.
  2. Create a new service request.
  3. For the Problem Type, select Service Instance Migration, then select the option appropriate for your migration:
    • From OCI-Gen1 to OCI-Gen2
    • From OCI-Gen2 to OCI-Gen2
    • From OCI-Classic to OCI-Gen2
  4. Provide the following information in your service request:
    • The URL of your source instance (the instance you’re migrating from)
    • The URL of your target instance (the instance you’re migrating to)
    • If you use Akamai delivered by Oracle, mention that so we can update the URLs in your Akamai configuration after migration
  5. Provide the preferred date you would like migration to start. We recommend that you give two weeks advanced notice.

    Note:

    We'll attempt to schedule your migration based on your requested date, but this may not always be possible given competing ongoing activities.
  6. Submit your service request.

    After Oracle Support receives your migration service request, they'll work with you to finalize a date that works for you and Oracle, and the service request will be updated with the date and time your migration will start.

  7. Confirm in the service request that you approve the migration start date and time.

Updates will be made to the service request to show how the migration is progressing. The data migration will be done at the back end; no action is required at your end other than to keep up with any service request updates, and to validate the migration after it's done.

The Migration Process

Here's what happens during the migration:

  1. Oracle Support updates the service request when migration begins.

    Important:

    At this point, you must not make any changes to your old (source) instance. Any changes made after migration starts won't be migrated to your new instance.
  2. Your content and configuration data is exported from your old instance (the source), and imported into your new instance (the target).
  3. When the migration is complete, Oracle Support updates the service request, and you're asked to validate your new instance to make sure everything is working as expected.
  4. If you find any problems, note them in the service request. Oracle Support will work to resolve the issues, and will let you know through the service request when the instance is ready for validation.
  5. When everything is working as expected, note in the service request that you accept the migrated instance.
  6. Delete the old instance so you won't continue to be charged for it.

Finalize the Migration

If your old instance integrated or communicated with other services or applications, either directly or through REST API calls, you might need to perform post-migration tasks.

The following items apply service-wide:

  • Credentials aren't migrated, so you'll need to reconfigure user credentials for all integrations that use them.
  • The Oracle Content Management URL pattern is different, so you'll need to update the URLs in your integrations that use them.

    The old URLs used the following pattern:

    https://<service-name>-<account-name>.<region>.oraclecloud.com/documents

    The new URLs used the following pattern:

    https://<service-name>-<account-name>.<service-type>.ocp.oraclecloud.com/documents

Integration Things to Do After Migration
Oracle Integration
  • Reconfigure credentials.
  • Update Oracle Content Management URLs in Oracle Integration Cloud.
Oracle Commerce Cloud
  • Reconfigure credentials.
  • Update Oracle Content Management URLs in Oracle Commerce Cloud.
Oracle Content Capture
  • Reconfigure credentials.
Oracle Process Cloud Service
  • Reconfigure credentials.
Oracle Eloqua Cloud Service
  • Reconfigure credentials.
Oracle Intelligent Advisor
  • Reconfigure credentials.
Oracle Cobrowse Cloud Service
  • Reconfigure credentials.
Responsys
  • Reconfigure credentials.
Visual Builder Cloud Service (VBCS)
  • Reconfigure credentials.
  • Update Oracle Content Management URLs in VBCS components.
CDN/Akamai
  • If you use Akamai delivered by Oracle, we'll update the Oracle Content Management URLs in your Akamai configuration after you verify your migration. Otherwise, you must update the URLs in your CDN configuration yourself.
REST API calls
  • Update Oracle Content Management URLs in any REST API calls.
Client SDK/CLI usage
  • If the URL is persisted/cached locally on the client side, then update Oracle Content Management URLs in the configuration.
Connectors
  • Reconfigure credentials.

Note:

Any bookmarks to content on your old instance will no longer work because the URL of your new instance has changed.

Communicate the Change to Users

Communicate the new service URL to your users. Desktop and mobile users will need to configure their devices with a new account and resynchronize all content.