Migrating from IIB v10 to ACE on Cloud Pak for Integration

It's not just an upgrade — it's an upgrade with modernization

When IBM Integration Bus went out of support, everyone started moving to App Connect, the new label. But something had changed underneath.
~Shahbaz Ali

1. Introduction

IBM introduced App Connect (IIB v11 and beyond) in late 2018/2019 as part of a broader journey from monolithic services toward microservices architecture. At that point you had a choice: do a straight version upgrade on the same stack, or go all-in on Cloud Pak for Integration and re-platform onto containers.

In this post I won't just walk through the migration steps — I'll also share what I learned from running a migration/modernization project like this end to end.

ACE supported migration paths for IIB v10: https://www.ibm.com/docs/en/app-connect/11.0.0?topic=migration-supported-paths

2. Context

It's worth remembering why everyone was migrating and modernizing at the same time. That era was dominated by SOA, middleware, and ESB terminologies. I remember working with App Connect when it was so called the message broker — built on top of the same robust IBM MQ backbone, acting as the orchestrator/aggregator for every kind of integration.

Over time, IBM separated the integration layer from MQ into its own standalone product, and later split it again into independent servers. It's a pattern worth noticing: middleware's or client server methodology went from web servers, to application servers, and now back toward something closer to web containers again — just running as serverless containers instead of VMs.

Application servers can manage multiple web containers — technically, a web container typically manages one port or can be configured to listen on multiple ports, standard practice dictates assigning one primary port per instance to isolate application traffic.

Similar in App Connect, integration servers were separated from integration nodes, so they could run independently to support cloud-native, microservices-style deployments. If you want to understand more about middleware's just look at IBM's broader middleware portfolio:

3. Why we chose CP4I

Looking above on the quick history over middleware products App Connect is one of the most robust B2B/systems-integration platforms out there, and most banking middleware landscapes run on it precisely because of how well it handles core-banking integration. Most of our use cases had ACE sitting as a back-office integration layer.

As an architect, the rule I keep coming back to is: pick the right product for the use case, not the trend. The same way database selection follows the CAP theorem or a similar decision framework, integration platform selection needs its own criteria. I've seen plenty of migrations happen purely because "everyone else is doing it," only to get reverted back to custom solutions a year later — that needs a whole separate post on its own.

That said, here's why CP4I made sense for us specifically:

• Elastic capacity. Whenever we had a campaign or a load spike, our answer used to be "add another VM to the load balancer." Once traffic dropped again, those resources sat idle — we had no way to reclaim them for other applications.
• Container orchestration. Running CP4I means running on Kubernetes or OpenShift, which gave us built-in Horizontal Pod Autoscaling (HPA) — a much better fit for fintech's traffic patterns.
• Faster deployments. faster time-to-market.
  

If you want to go deeper on the "why, when, and how" of choosing a product for agile integration, Kim Clark's mentioned useful links on agile integration architecture is worth the read: community.ibm.com — agile-integration-architecture-use

4. Target Architecture

Migration architecture starts with decomposing (or grouping) your services and applications. In an ideal world you'd run one service per container — but nobody actually recommends that, because you'll spend the rest of your career just maintaining it. Strike a balance: group services along business boundaries, count your existing Execution Groups (Integration Servers/Runtimes), and if the count is high, consolidate further based on dependencies, artifacts, expected load, and — always — your available resources.

Here's roughly what that target architecture looked like for us:

5. Migration Approach & Strategy

Once the analysis and grouping sheet are done, you can plan the migration itself: estimation, cutover sequencing, CI/CD pipeline, security layers, and so on. Here's the approach we followed:

• Improve logging first. If logs are currently written via DB calls or MQ, move away from that. Shift to Kafka, or use monitoring profiles, or an ELK/ECK stack if you have one, or OpenTelemetry if you want to go further. See App Connect monitoring profiles: https://www.ibm.com/docs/en/app-connect/13.0.x?topic=basics-monitoring-profiles
• Group and decompose based on business domain, operations, security boundaries, backend dependencies, and libraries.
• Move MQ out of the pod. Best practice is a remote MQ connection to a separate MQ server outside the container — you can build custom images with MQ bundled in, but unless you have a strong reason to, stick with the out-of-the-box setup so patching and upgrades stay simple and Run MQ as a standalone Native HA deployment inside the cluster - 3-replica Native HA group gives you quorum-based failover.
• Rollout Plan: it was something you'd need to focus on the beginning that was the pain we faced, but you need to analyze more effectively while considering cutoff with Big Bang approach or a graceful switchover.

There are really two flavors of refactoring during a migration like this:

1. Lift-and-shift — adjust flows/configuration just enough to make them container-ready.
2. Refactor/revamp — rebuild to actually use cloud-native capabilities. This is a never-ending journey, not a milestone.

Given a fixed timeline, you'll usually need a mix of both: pick the refactoring that matters most for go-live, and defer the rest.

My own focus areas for this migration were:

1. Separate MQ from ACE entirely — remote connection policy only.
2. Rebuild the logging framework without any queue or DB call in the hot path — server logs plus Kibana (OpenShift's built-in stack is capable, but plan for log offloading too).
3. Global caching doesn't exist as-is in a container world — mock it with in-memory caching first to avoid a large code-refactoring effort up front.
4. Prefer shared libraries over static ones — smaller (BAR) deployment footprint, better efficiency.

You'll likely find more focus areas as you go — just don't let them push your deadline. Anything that isn't critical for cutover can be refactored afterward.

Build vs. buy: a broader observation

Something worth sitting with before you commit to a platform at all: I've seen organizations move toward IBM's integration stack, and just as many move away from it back to something like Spring Boot. Both camps usually have good reasons — this isn't a case of one side being wrong.

The way I'd frame the decision: think about the capabilities you actually need, not the trend you're following. If you already have a solid, mature custom framework that covers your requirements end to end, building on it is a perfectly reasonable choice — plenty of teams don't need everything a commercial product bundles in. But if you're expecting the breadth of functionality a mature enterprise product ships with — proven integrations, tested edge cases, a support team behind it — that's exactly what the license cost is buying you: a standard, supported way to implement, deploy, and upgrade, backed by a solution that's already been battle-tested elsewhere.

It's also worth remembering how much of that "product" is itself acquired, open-source-derived technology rather than something built from scratch. IBM's own portfolio is a good example — Red Hat, Software AG's webMethods, and StrongLoop (the Node.js team behind much of what API Connect is built on) are just a few of the acquisitions that now sit inside the products discussed in this series. The full list of IBM's mergers and acquisitions is worth a skim if you want a sense of how much of "the platform" was bought rather than built in-house: en.wikipedia.org/wiki/List_of_mergers_and_acquisitions_by_IBM

None of that makes the build-vs-buy call for you — but it's a useful lens when you're evaluating whether a commercial platform's price tag is buying you real capability, or just a label.

6. Challenges Faced

Technical: Feature/policy parity gaps between IIB and ACE meant some custom extensions and protocol behaviors had to be rebuilt rather than migrated as-is. Observability was a real early gap — years of monitoring habits didn't map cleanly onto a containerized runtime. Removing legacy functions during refactoring got messy fast, and a handful of them simply couldn't be fully tested — either tied to a narrow business case or dependent on a third-party UAT environment we didn't fully control.

Organizational: Moving a long-standing IIB team onto OpenShift, GitOps, and container operations is a genuine skill shift, not just a tooling change. Getting stakeholder buy-in for a modernization (versus a "simple" version upgrade) took real change-management effort — people had to understand why the extra work was worth it.

Operational: Downtime windows had to be negotiated carefully against SLA commitments, and rollback planning had to be solid before any cutover. The bigger operational question, though, was node parity: if your existing nodes are exact replicas of each other, a straightforward cutover works fine — but if some carry node- services difference or dependent systems load limitation then a graceful switchover is the safer path.

7. Risks & Mitigations

8. Lessons Learned

• Modernization is a journey, not a project. Treat the target architecture as a direction, not a finish line — some refactoring will always be "next phase."
• Move MQ out of the pod early. It's one of the highest-leverage decoupling decisions you can make, and it gets harder to retrofit later, and always use queue for transactional load/traffic/messages where they are meant to be persistent/unique.
• Fix logging before you fix anything else. DB- or MQ-backed logging is one of the most common things that quietly breaks (or quietly kills performance) once you're running in containers
• When nodes aren't uniform, switch over gracefully — don't big-bang it. If some existing nodes carry node-pinned work (timer jobs on a specific ESB instance, for example), make the new OCP/CP4I environment act like a single node behind your existing load balancer, and shift services across gradually rather than cutting everything over at once.
• Queue-based inbound integration makes a graceful switchover much easier. Most of our inbound traffic reached ACE through JMS queue listeners rather than direct point-to-point calls — that decoupling meant we could shift load without callers caring which node picked it up, which worked in our favor for this approach.
• Precise load estimation matters more than it seems. Switching over service-by-service takes longer than a single cutover, but it's far more forgiving — and it only works well if your load estimates going in are accurate.

9. Conclusion

Across the posts, I've tried to walk through real migration and modernization efforts — but the truth is, no two of them look the same. The approach always depends on demand, resources, and context. If you're starting/on an IIB-to-ACE or ACE-to-ACE (CP4I) migration, my honest advice is: don't just lift and shift the flows — use the migration as the forcing function to fix the things you always meant to fix (logging, caching, MQ decoupling). You have a limited window where the business already expects some disruption; that's the best time to do the hard parts.

I'd love to hear how your migration went, or where you disagreed with the approach above — drop a comment or connect with me on LinkedIn. 

This post is part of my series: Reimagining Integration Migrations with Modernization
https://lnkd.in/p/dZwzq27P