IBM® App Connect Enterprise Version 11.0 supports parallel migration and extract migration to migrate your application logic to Version 11.0 systems.
If you want to reproduce the integration node function on another computer, you can use parallel migration to associate the application logic on your existing integration node with a separate Version 11.0 integration node.

By using extract migration, you can migrate existing integration server configuration and resources to IBM App Connect Enterprise Version 11.0. Please refer to this Knowledge Center link for more details.

In this article, we attempt to provide a schematic view of migration options from IBM Integration Bus V9/V10 and some key considerations which may assist you in deciding your migration strategy. Although there is no direct migration path available from WMB V8 to ACE V11 (via mqsiextractcomponents), we depict the possible approach you could adopt to migrate from WMB V8 to ACE V11.

Migration options

IIB V9/V10 to ACE V11

Migration Approach – IIB V9/V10 to ACE V11

Option 1 – When source code is available

BAR files/Message flows projects, config services etc. available

Extract Migration
Use mqsibackupbroker & mqsiextractcomponents

Parallel Migration
You may choose to deploy existing artifacts as-is or may need to refactor for various reasons (See the refactoring section)

  1. Refactor: Import existing PIs to V11 Toolkit, redesign flows as necessary, create policies, create new BARs and deploy
  2. Replatform: Deploy the BARs on V11 supported platform
  3. Deploy to the standalone integration server (SIS) or integration node, integration server architecture
  4. as-is: Deploy existing BARs to ACE V11

Option 2 – When source code is not available


BAR files/Message flows projects, config services NOT available

  1. Take a backup of the IIB V9/V10 integration node using the mqsibackupbroker command
  2. Move the backup to the desired ACE V11 system
  3. Use the mqsiextractcomponents command to perform migration
  4. Extract to the standalone integration server or integration node, integration server architecture
  5. The msgflows with discontinued flow nodes will not migrate

WMB V8 to ACE V11

Migration Approach – WMB V8 to ACE V11


Option 1 – When source code is available


BAR files/Message flows projects, config services etc. available

Parallel Migration
You may choose to deploy existing artifacts as-is or may require to refactor for various reasons (see the refactoring section)

  1. Refactor: Import existing PIs to V11 Toolkit, redesign flows as necessary, create policies, create new BARs and deploy
  2. Replatform: Deploy the BARs on V11 supported platform
  3. Deploy to the standalone integration server or integration node, integration server architecture
  4. as-is: Deploy existing BARs to ACE V11


Option 2 – When source code is not available

BAR files/Message flows projects, configservices etc. NOT available

  1. Perform inplace migration from V8 to V10 using mqsimigratecomponents command
  2. Take backup of V10 Node and move it to V11 System
  3. Use mqsiextractcomponents command to perform migration
  4. Extract to the standalone integration server or integration node, integration server architecture
  5. The msgflows with discontinued flow nodes will not migrate

Moving on-prem workload to IBM Cloud (Managed service)

Migration Approach – moving workload to IBM Cloud (Managed service)

Recommended Topology – Hybrid deployment

Moving parts of the integration to cloud while retaining some on-premise closer to enterprise systems.
These two deployments can seamlessly talk to each other using a purpose built Switch server & callable flow technology.

Refactor existing Apps based on the following:

  1. Refer to IBM Knowledge Center to learn which features/functionality/nodes are not available in the Cloud. Keep such flows on-prem.
  2. Flows that heavily depend on on-prem data (local files/ backend DBs etc.) and require high performance, low latency should be deployed on-prem.
  3. Use callable flows to get the data from on-prem system.

Use a phased approach to move workload from On-Prem to On-Cloud.

IIB V9/V10 to ACE V11 on ICP

Migration Approach – IIB V9/V10 to ACE V11 on ICP

Option 1


You can deploy your existing BAR files using the ACE dashboard on ICP 3.1 → (Recommended)
https://developer.ibm.com/integration/blog/2018/11/23/app-connect-enterprise-v11-on-ibm-cloud-private-v3-1/

Option 2


You can also create your own Docker image or Helm charts for ACE using templates on ot4i
https://github.com/ot4i/ace-docker
https://github.com/ot4i/ace-helm

Refactoring

When do I need to refactor?

  • Behavioral changes between source and target versions – Refer to this Knowledge Center link
  • Deprecated/discontinued nodes – Refer to this Knowledge Center link
  • Reduced OS Platform coverage – needs re-platforming
  • Integration node vs standalone integration server (SIS) deployment topology
  • Independent projects – need to be converted to Application Projects in ACE
  • Fine grained deployment – restructure BAR files
  • Hybrid Integration Scenario – interfacing with SaaS apps

Benefits of refactoring


While your existing Apps might work as-is on ACE V11, you may want to consider refactoring your Apps where possible for:

  1. Enhancing productivity
  2. Agility to deploy new changes
  3. Modernisation of Apps.

For example:

  • Enhance existing applications to take advantage of newest features like RESTAPI projects to expose webservices based flows as APIs, use callable flows for hybrid integration, in-memory aggregation etc.

A few additional points to consider if refactoring to deploy to ACE on ICP

  1. MQ affinity – Do you require local MQ or can you connect via the MQ client connection?
    By regrouping flows in the BAR file, you can spin up ‘ACE only’ images for non-MQ based flows, which means a smaller footprint of the container and less moving parts and thus easier to maintain
  2. Group related services together
  3. Deploy critical services or high volume services in its own integration server for independent scaling
  4. Is persistence of the data required? If yes, persistent volume and PV claim will need to be configured
  5. Interface with SaaS or backend legacy systems

Parallel Migration

You can use parallel migration to perform a staged migration process by creating a new Version 11.0 integration node to run in parallel with your existing integration node. You can then migrate your application logic from your existing integration node to your new integration node.

Advantages of Parallel Migration

  • You don’t need to stop your existing brokers during migration
  • You can migrate to any hardware or computer
  • Code changes can be made in parallel with migration to take advantage of new features in the product
  • You can choose which components to migrate in a controlled way
  • You don’t need to stop your existing brokers during migration
  • You can make changes to your client configurations

Join The Discussion

Your email address will not be published. Required fields are marked *