Why Move from API Connect v5 to API Connect v10?

Written by Ali Akthar

Technical Account Manager

IBM has always been working on innovation and focused on upgrading the technology and the functionality when it comes to Enterprise-grade applications.

Over the various iterations in terms of the API Connect versions IBM released; IBM has always been the market leader in many of these areas. In addition to the fact that IBM has consistently delivered new stories and new reasons to jump onto the latest infrastructure.

One of the key reasons to update API Connect v5 to v10 is that it provides customers the flexibility to deploy however they like and wherever they like. Whether the customer wants to do the deployment or on Cloud Pak for integration, or even as a stand-alone solution deployable on-prem or any other cloud, or if they would like to bring this on to their own OpenShift or Kubernetes cluster or Open Virtualized Appliances on any VMware. In addition, IBM API Connect, v10 also includes an IBM-managed API Connect reserved instance offering a single-tenant example with the ability to add on-premises gateways.

In API Connect v5, IBM has delivered excellent enhancements so far, but an end-of-life support date is scheduled for April 30, 2022. IBM API Connect v10 includes considerable enhancements and deployment flexibility over v5.

How is Upgrade Going to Work?

IBM API Connect v5 to v10 is a complete version migration, and it is going to be a direct migration which means there will be no hops in between.

There is a tool for Migration called API Connect migration utility and for that customer needs to identify the Phases of Migration Upgrade. In addition to that, when selecting an API gateway service, organizations should keep in mind what form factors of conversion they would want to migrate from v5 and then deployment along with architecture. There would be development work to modify or update API assemblies of existing APIs and to use new capabilities of the version. An emulation mode is available in the platform, and a porting function in the migration utility. This will help reduce the development cost of migrating to this new gateway service. Organizations can select the native API gateway to future proof and benefit from a significant performance improvement.

Organizations can start planning on this by looking at the technical documents in detail to understand the best practices and define an actual timeline, future understanding architecture, and the level of customization of the environment itself.

Planning examples: Location to deploy on-prem, or hybrid.

Migration Process

  • Step 1: Organizations can choose from the choice of deploying form factor, read and complete the installation of v10 topology.
  • Step 2: Download the latest API Connect Migration Utility (AMU) with the most recent version, which is available on IBM Fix central. The file name should be formatted to apic-migrate-utility_v10.0.x.x
  • Step 3: While preparing for migration, organizations must ensure that the minimum source version should be before migrating. This is required to access the DBExtract command, which is used to extract the API catalog from v5.
  • Step 4: The next step is to migrate using the Full auto migration approach and the semi-auto migration approach. In the Full auto approach, all the organization's artifacts, including APIs, Products, Catalogs, Consumers, Subscriptions, Custom Policies, Gateway Extensions, will be migrated. While in Semi-Auto Migration, all the customizations will be handled, such as PDUR and portal customization.

The migration process will allow customers to migrate as much or as little content as required. In addition, this will enable organizations to iteratively migrate data and push data as many times as needed. Within Migration, there are two paths: Simple Migration Path and Advanced Migration Path.

Simple Migration Path

This basic migration process is recommended for scenarios where ease of Migration is a top priority; Organizations can take advantage of v5 compatibility built into gateway services and performance improvement over the v5 version. Thus, no further modifications to existing API assemblies would be required.

Extract v5 Data

Organizations can extract v5 configuration on v5.0.8.7, and above, including APIs & Products, etc. using the command "dbextract" on the v5 CLI enhanced if using Portal Delegated User Registry (PDUR), & then use the pdur_user_export command on the Developer Portal CLI to export data.

UnPack and Map

Organizations can import and unpack the backup to YAML files using archives, unpack command in API connect migration utility (AMU), specify the mapping from gateway service on v10 to v5, which allows flexibility to map to new resources added in v10 to reflect any changes on v10 setup topology through mapping files if desired.

Validate & Push

Organizations can validate the mapping and prerequisites using API connect migration utility (AMU), simulate a migration with dry-run command & move the APIs and configuration to v10 using the push command on the AMU to complete Migration.


Organizations can test the API endpoints to ensure successful migration verify user access, onboarding, etc.

Advanced Migration Path

With an advanced migration approach, organizations can work on the performance-critical scenarios, take advantage of the new gateway technology for larger workloads, porting steps that require manual work, and any new development.

Convert API Assemblies

Now, all other steps performed are identical as in simple migration path run porting command port-to-apigw will reshape API assembly content to take advantage of new gateway features updates to assembly code may be required (e.g., gateway script code within policies).

Downtime Consideration

Migration from API Connect v5 to v10 requires two separate API Connect environments to be set up. As such, the v5 environment being replaced can remain up and running while the v10 Migration is taking place. After Migration is completed, routing can simply be switched to the new v10 installation without downtime.

Migration OAuth provider and OAuth Secured APIs

In v5, OAuth (security) providers are a specialized type of API that are published within products. In v10, OAuth Providers are first-class object services directly published in the organization and are not APIs published within products. Organizations may have some v5 products that only contain OAuth (security) provider APIs. Since only OAuth is the APIs that do not incorporate any Open API definitions in V10, they are not published. All products in v10 must have at least one Open API definition. The AMU migrates all v5 OAuth providers to the new first-class OAuth object type for v5c and API DataPower Gateways.

Royal Cyber your Migration Partner

Migrations are not always easy but considering all the benefits IBM API Connect v10 brings you, it is worth it. However, everybody will have to upgrade in a year or two, so why not migrate now and encounter all the benefits – additional value, new architecture, and enhanced performance. If you plan to migrate, need help, Join us for a Webinar, where we discuss about the "Strategies to Migrate IBM API Connect". Also, Discover how this Leading Manufacturer Speeds Up Software Release Cycles with Amazon EKS and APIC. For more information, you can email us at [email protected] or visit www.royalcyber.com.

Leave a Reply