Migration overview

An overview of the migration steps, the supported paths, and the initial planning for a v2018 to v10 form factor migration.

Restriction: Beginning with version 10.0.5.5, a direct upgrade from version 2018 is not supported using form factor migration. To upgrade from version 2018, upgrade to 10.0.5.4, and then perform the upgrade to the newest release.

What does form factor migration involve?

  1. The health of the source v2018 deployment is verified, and any necessary cleanup of the database is completed.
  2. Scripts are run against the source deployment to extract Management and Portal data.
  3. The v10 target deployment is installed.
  4. A mapping file of the API Connect endpoints is generated, mapping your v2018 endpoint URLs to the endpoints of the v10 deployment.
  5. Scripts are run against the target deployment to load the data from the v2018 source deployment, applying the endpoint mappings.

The scripts that are used for the migration are in Python and are supported on Linux and MacOS. On Kubernetes and OpenShift the scripts must be run from a client computer that has access to your Kubernetes or OpenShift cluster. On OVA deployments, they are run directly on the Management and Portal VMs.

Supported v2018 to v10 migration paths

The supported migration paths cover two use cases:

  • Migrating from a v2018 system on one form factor to a v10 system on another form factor.
  • Migrating from a v2018 system on one form factor to a v10 system on the same form factor, when you want to change the API Connect endpoint URLs.
Table 1. Supported migration paths to API Connect v10
Source deployment platform of API Connect v2018 Target deployment platform, based on API Connect v10
Kubernetes Cloud Pak for Integration
Kubernetes OpenShift Container Platform
Kubernetes Kubernetes, when moving to a different cluster, resulting in hostname changes
   
VMware Cloud Pak for Integration
VMware OpenShift Container Platform
VMware VMware
   
OpenShift Container Platform Cloud Pak for Integration, moving to a different cluster, resulting in hostname changes
OpenShift Container Platform OpenShift Container Platform, moving to a different cluster, resulting in hostname changes
   
Cloud Pak for Integration Cloud Pak for Integration, moving to a different cluster, resulting in hostname changes

v10 migration planning

Points for consideration in v2018 to v10 migration planning:
Note: The v2018 deployment is referred to as the 'source' system, and the v10 deployment you are migrating to is referred to as the 'target' system.
  • Do you want to migrate all your v2018 source data?

    You do not have to migrate all your v2018 Portal and Gateway subsystems. You can start with a v10 target deployment that has one gateway and portal, and migrate your v2018 data to it. Later you can then add more gateway and portal subsystems to your v10 deployment and migrate your remaining v2018 subsystems. This method is called a staged migration.

    Other v2018 data such as organizations, products, and APIs that you do not want can be deleted from your v10 Cloud Manager and the API Manager UIs.

  • Delta changes

    The first step in the migration is extracting the data from your v2018 source deployment. If the v2018 deployment continues in use after the data extraction, then any new changes will not be migrated. You must manually apply any delta changes to your v10 target deployment after the v2018 extracted data is restored.

  • Sizing

    Ensure that v10 capacity planning is done. Ensure you have sufficient memory, CPU, and disk size, to meet your requirements. See Planning your deployment.

  • Time to complete migration.

    The time taken to complete migration depends on the size of your Management database and number of portal sites.