Migration steps

Plan the migration, install a new v10 deployment, and move data from v5 to v10.

About this task

At the highest level, the migration steps are:

  • Plan your migration.
  • Install and configure a v10 system to best meet current needs and integrate v5 data.
  • Backup your v5 data and migrate the data to your new v10 deployment.

Procedure

Complete the following steps:

  1. Plan your migration:
    • Read Migration overview.
    • Ensure you have supported versions of the software. See Supported versions.
    • Plan your new v10 deployment. When moving from v5 to v10, use the opportunity to review your topology, user registries, provider organizations, etc. You might want to look at the existing data on the v5 system, and do some cleanup before running the extract. This will help ensure only objects that are required in v10 are migrated over.
    • If you are migrating to DataPower API Gateway, migrate a proof-of-concept deployment before migrating your entire v5 backup. Migrate 10 to 20 of your most commonly used v5 APIs and test them to determine which migration utility settings you may need to convert your APIs to DataPower API Gateway.
  2. Install and configure a v10 system.

    Install and deploy v10 with usage of the incoming v5 data in mind. Before you push your v5 data to v10, your v10 system must be up and running, with gateway services, provider organizations, user registries, etc, ready to receive the data.

    Important:

    Verify that you completed the following steps as part of deploying your v10 environment:

    • Ensure that you create the same number of API Managers as on the v5 deployment.
    • Use the Cloud Manager to configure topology. See Defining your topology.
    • If your v10 topology uses identical names and quantities of gateway services as v5, the migration utility automatically maps configuration information. If your v10 configuration uses different names or a different number, you must manually map the v5 gateway services to v10 gateway services. You will be guided to map gateway services in a later step. To review the mapping requirement, see Mapping a gateway service.
    • Review Gateway types and configurations:

      API Connect v10 supports two types of gateway services: DataPower Gateway (v5-compatible) and DataPower API Gateway. The DataPower API Gateway type is not supported for API Connect v5. When you register your gateway service on your v10 system, you must select the gateway service type. If you select API Gateway, your migration process must include a step to convert (port) the v5 API Definitions from the DataPower Gateway (v5-compatible) format to the DataPower API Gateway format. The migration utility provides an option to do the porting. Command line instructions are provided in a later step.

      If migrating to datapower-api-gateway, confirm xml-manager is enabled in default domain of all gateways.

      To review gateway types and configuration, see API Connect gateway types and Registering a gateway service.

    • Create the provider organizations. If your v10 configuration for provider organizations uses different names or a different quantity, you must manually map the v5 provider organizations to v10 provider organizations. You will be guided to map provider organizations in a later step. To review the mapping requirement, see Mapping a provider organization.
    • When migrating catalog spaces in an provider organization that uses a local user registry (LUR), ensure that the LUR is configured with the visibility setting of either Public or Custom. If set to Custom, ensure that the provider organization is selected. For information on configuring visibility, see Setting visibility for a user registry.
    • Configure user registries such as LDAP, as needed to match the user registries used for v5 users.
    • The migration process includes migration of users. Configuration of users into API Connect includes sending email to users to set up their accounts. The recommended way to do this during an automated migration is to set up a temporary SMTP server. One open source option for SMTP is MailHog. See https://github.com/mailhog/MailHog. When the migration process is complete, be sure to replace your temporary SMTP server with the permanent SMTP server for your API Connect v10 deployment.
    • Create the Portal services that you want to use with the Catalogs that you plan to migrate. You will configure the catalogs to the Portals after the migration data is pushed to the v10 system.
  3. Backup your v5 data and migrate the data to your new v10 deployment.
    1. Download the migration utility. See Obtaining the API Connect Migration Utility.
    2. Determine if your v5 system contain catalogs that user a Portal Delegated User Registry (PDUR).

      Use of the PDUR was optional in v5. Migration of systems that use PDUR is very similar to migration of systems that do not use PDUR, however a few additional steps are needed. If you are not sure if your v5 catalogs use PDUR, check your v5 registry settings. See Selecting the Portal Delegated User Registry.

    3. Continue with instructions that apply to your deployment: