Migration from API Management to API Connect

Before we delve into the details of migration, let’s define the two platforms

API Management

API management offering provides us a platform that let us manage and control the set of APIs and expose to application developers.

API management platform makes it simple to deploy APIs, easy to define the structure, to understand how we will access it and control those APIs with security.

API Connect

IBM API Connect is an integrated offering, which provides customers an end to end API life-cycle (Create, Run, Secure and Manage) experience. It provides capabilities to build model-driven API’s, micro-services using Node.js loopback framework, run them either on-premise or on-cloud, secure and manage the same using management, gateway server and developer portal.

1. Components:

API Management

API Management

Developer Portal

It presents a tailorable self-service web-based portal to application developers to take a look at, uncover, and subscribe to APIs.

Management Server

It provides tools to interface with various servers and holds the data. It runs Cloud Management Console (utilized by cloud administrator to create, manage and monitor the cloud and other admin tasks) and API Manager Portal (used by API developers, Product managers, admins etc.)

2. Migration Approaches

Following are the approaches that we can take to upgrade to API Connect.

3. Pre and Post Migration Comparison

Below is the comparison to see what will change after the upgrade.

  • From Plans ----------> Products
  • Environments ----------> Catalogs
  • Basic/Advanced Developer Portal ----------> only Developer Portal
  • SSL Profiles ----------> TLS Profiles
  • OpenAPI (Swagger 2.0) – Without Operations/Assembly Flow ----------> with Operations / Assembly Flow

4. Upgrading Servers in IBM API Management

To successfully upgrade the IBM API Management solution, we need to perform operations on both the Management cluster(s) and Gateway cluster(s). The following diagram illustrates how the sequence of events unfold as we apply maintenance to the various servers in the API Management solution.

User invokes command on each server in turn

In the diagram above, there are four Management servers in the Management cluster and two Gateway servers in the Gateway cluster.

Steps 1-6 illustrate the upgrade sequence for the Management cluster. Upgrade the Management servers one at a time. The management server is momentarily disconnected from the cloud after the upgrade and remains idle till the last server is updated. We can begin with any non-primary Management server in the Management cluster--upgrade the Primary Management server last. Substantiate that the upgrade is successful before starting the upgrade for the next Management server. When the last Management server (Primary) upgrade happens, the Primary Management server automatically activates and reactivates all the other upgraded servers in the Management cluster. The role of the server (for example, Primary, RSS) can be viewed under server details for each server in the Clusters tab of the Cloud Management Console (CMC).

Steps 7-10 illustrate the sequence in which the Gateway cluster should be refreshed after upgrading the Management clusters.

5. Testing the Upgrade Process

It is important to test the upgrade process as it helps us in validating the upgrade path without jeopardizing our active API management installation.


Below is the procedure to test the upgrade process:

  • Verify that the Informix database for the existing system is in a good condition.
  • Install a new API Management appliance and ensure it is at the same version as the appliance that we want to upgrade.
  • Reinstate the configuration backup to our new appliance. After the backup is restored, any DataPower appliances that are in our main system appear in the restored system.
  • Configure a DataPower appliance to function with the restored system.
  • Run the upgrade command on the restored system, through the CLI.
  • After the system has upgraded, log in to the Cloud Manager to verify that the configuration for it is correct.
  • Log in to the API Manager to verify that our APIs, Products, and Catalogs are successfully converted to the upgraded format.
    • For APIs, check for any OpenAPI (Swagger 2.0) validation and assembly definition errors. APIs can be invoked for validation.
    • For Products, ensure that the Products are published to the correct Catalogs, and that any application developer subscriptions to Products are also correct.
    • For Catalogs, ensure that any users, roles, and Developer Portal settings are also correct.
    • Install and configure a Developer Portal site to ensure that our APIs and Products are displayed and function correctly in the Developer Portal.

Leave a Reply