For years, IBM was seen as legacy integration technology that many organizations wanted to move away from. With recent acquisitions and platform changes, IBM is now more relevant than ever. Here's how to take a fresh look at your IBM estate before making the next modernization decisions.
Read the summary (AI-generated, human-reviewed)
- IBM's integration portfolio has changed significantly through acquisitions such as webMethods, StreamSets, Confluent, HashiCorp, and Red Hat.
- There are three good reasons to reassess your IBM estate now: upcoming support deadlines, increasing regulatory and sovereignty requirements, and the need to support AI agents in a governed, secure way.
- Rather than starting with a migration project, organizations should begin with a thorough inventory to identify the real constraints and determine the best path forward.
Fifteen years ago, if you asked an enterprise architect how their systems talked to each other, you got an answer with IBM in it. Message broker in the middle, MQ underneath, DataPower at the edge. It was heavy and expensive. And it also worked.
Then iPaaS arrived, and many organizations decided they had had enough. Some got out cleanly. Rather more are still, six or seven years later, somewhere in the middle (a polite way of saying they are paying two vendors).
And while everyone was busy not finishing those migrations, IBM acquired new services. Almost nobody noticed this.
IBM integration products still have a massive install base
It made sense to try to move away from IBM. Their products were built for a data center rather than the cloud, and the iPaaS alternatives were really quicker to build on and cheaper to start with.
What the business cases got wrong was the inventory. A twenty-year-old integration layer is never “about 3,000 interfaces”. It is 3,000 interfaces, plus EDI flows agreed with a supplier in 2009 where nobody on either side still works there, plus the batch job that runs once a quarter and on that night matters more than anything else you own, plus error handling that encodes a business rule somebody decided in a meeting and never wrote down. You can migrate all of that, but it is closer to archaeology with a go-live date than to a technology project.
In our experience, these programs are rarely canceled. They stretch. Year one, assessment. Year two, pilot. Year three, priorities shift, and half the team goes somewhere that gets more executive attention. The old platform stays up because it has to, and now you run both, staff both, and govern neither.
That is why so many IBM integration estates are still in production today.
Five questions to assess your IBM integration estate health (and be honest)
- Are you on a version that is out of support, or will be within a year?
- Is it one big deployment, where any change puts everything at risk?
- Is the license core-based, up for renewal, or just wrong for what you run?
- Does the license stop you from containerizing or scaling when you need to?
- Does every team build integrations and APIs its own way, with releases still done by hand?
Three or more yeses and your stack is worth a proper look this quarter - whether or not anything on the roadmap says so.
How IBM's integration portfolio changed: webMethods, Confluent, and HashiCorp
In July 2024, IBM bought webMethods and StreamSets from Software AG.
In March 2026, it acquired Confluent – the company behind Apache Kafka. HashiCorp closed in between. Red Hat was already in the building.
Taken together, that covers most of the ways enterprise systems actually talk to each other:
- Guaranteed transactional delivery, where losing a message is not an option, is MQ.
- Request-response between applications and partners is webMethods Integration and App Connect Enterprise (ACE).
- Event streams are Confluent.
- Files and B2B documents are MFT and B2B.
- Exposure and governance for all of it are via API Connect and the webMethods API Gateway, with DataPower at the edge and Red Hat and HashiCorp underneath.
Most estates need four or five of those at once, and bought them from four or five vendors, each with its own catalog, identity model, and idea of what monitoring looks like. That is where integration estates break - not inside any one product, but between them: the API that is governed, while the Kafka topic beside it is not, the file transfer nobody watches, the four consoles you check before you can say what happened last night.
When a vendor assembles a portfolio like this, the next move is a migration path to one strategic platform, announced at a conference and dreaded by everyone in the room.
IBM went the other way: unify the management layer, leave the runtimes alone.
IBM Integration (new naming covering both webMethods Hybrid Integration and CP4I) puts one control plane over both the webMethods API Gateway and the DataPower-based API Connect gateways, which removes the usual precondition - normally you rewrite before you can govern, and governance projects stall because the rewrite never gets funded. The same logic runs through the rest: one catalog, where Event Endpoint Management puts Kafka topics beside REST APIs so an event and an API are governed the same way: one substrate underneath, with infrastructure and secrets automated rather than ticketed.
The saving is not that any one product is more affordable. It is that you stop maintaining four catalogs, four identity models, and four different answers to the question of what happened last night. Our architects called federated API management the leading API trend for 2026 for exactly this reason.
This produces a second-order effect that matters more than any single product. Once integrations are containerized - App Connect Enterprise flows as integration servers on OpenShift, webMethods self-managed on Kubernetes, or consumed as iPaaS services - the artifact stops being tied to where it runs. With entitlements that follow consumption rather than deployment location, the same integration can sit on a VM this year, in a container next year, and in iPaaS after that, one workload at a time. At which point “the migration” largely ceases to exist as an event. What is left is a sequence of redeployments, each small enough to reverse - once the flows themselves containerize cleanly.
All of which is worth setting against the reasons for leaving in the first place: licenses that were too expensive, products built for a data center rather than for the cloud, and alternatives that were quicker to build on. The current stack answers most of that.
Three reasons to look at your IBM integration stack now
Two things are worth putting side by side:
- What is actually running in your estate today
- And what the assembled IBM stack can do that it could not three years ago.
Most organizations have never compared the two, because there was no particular reason to. There are now three and they run on quite different timescales. One has a date in the calendar. One is already law and waiting to be audited. One has no schedule at all because it moves at whatever speed your own business requires.
The first clock: App Connect Enterprise, December 2026
App Connect Enterprise v11 came off extended support in April 2026. Basic support for v12 ends on 31 December 2026. After that you can pay for extended support until December 2029 - a real option, and worth naming for what it is: paying more every year for a product that has stopped getting better.
Nobody upgrades a broker estate in a fortnight, and the install is not the hard part. Establishing what is deployed, who owns it, and which flows nobody dares touch is the long pole, which is why December is closer than it looks.
The version number is the least interesting thing here, though. Nearly every ACE estate we see carries the same three constraints, and only one of them is technical: a monolithic runtime where one restart is everybody’s restart, development still tied to the Toolkit, and a JVM generation behind where security would like it. ACE v13 on Cloud Pak for Integration addresses all of that, which makes the upgrade the straightforward half of the decision.
The second constraint is commercial, and it distorts architecture the most. Core-based licensing was priced when cores were scarce; modern servers have plenty, so the same workload costs more with every hardware refresh, separate contracts bill you three times for one platform, and elastic scaling stays theoretical. You end up with an estate sized to fit a license rather than demand.
The third never makes it onto a slide: the people. Manual promotion, no automated tests, and - the common case, not the extreme one - one person who genuinely understands how it all hangs together. Not a criticism of them; it usually means fifteen years of being good at the job. But it makes recovery time a function of one person’s holiday schedule, and ACE skills here are scarce and ageing.
None of that automatically means migrate. It means knowing exactly where you stand well before December.
The second clock: the regulator
In Northern Europe, NIS2 and DORA already apply, and the AI Act’s transparency and enforcement provisions arrived this August. What comes next is not a new law but audits, supplier questionnaires, and someone asking you to evidence it. Between those and a defense sector with rules of its own, the questions have become specific: not where the data sits, but who operates the environment, who holds the keys, and whose courts have jurisdiction over the control plane. Gartner expects more than 75 percent of enterprises outside the United States to have a sovereignty strategy by 2030.
Integration is where that stops being policy and becomes design, because it is the layer that touches everything else - and it usually arrives as a constraint that sounds small and is not.
On a recent API program for a Central European bank, the one that shaped the whole delivery was this: nobody outside the bank could touch production. Ever. Not to deploy, not to read a log during an incident. And the same split that makes the rest of this work - control plane in one place, runtimes wherever the rules insist - is what makes a constraint like that answerable at all.
The third clock: AI agents need governed access
Every client we work with is running AI pilots. Almost all of them only read: they summarize, draft, and answer questions. Very few are allowed to change anything - place an order, release a payment, update a customer record - because that means writing into the systems the integration layer has been mediating for twenty years. The gap is not model quality. An agent that acts needs governed access to live data and a controlled way to use it, with the same policy enforcement, rate limiting, and audit trail as any other consumer gets. Stricter, arguably - it is the only consumer whose next call you cannot predict from its last one.
Recent webMethods releases expose governed flow services to agents as Model Context Protocol tools, so an agent is authenticated, rate-limited, logged, and confined to what it has been granted - enforced by the runtime, not the prompt. A prompt is a request the model can be argued out of; a policy in the runtime is evaluated whatever the caller asks for.
The gateway side has moved too. API Connect now carries an AI Gateway, which treats calls out to model providers as ordinary managed traffic: one place to apply policy, rate limits, and response caching, so an agent stuck in a loop does not run up an unbounded bill - plus masking of sensitive data, audit trails, and a dashboard showing which AI services are actually being used and what they have cost. The same release also lets you generate an MCP server directly from a published API, so the tools an agent is handed are the APIs you already govern, accessed through the gateway you already run.
Why have IBM's integration portfolio changes gone largely unnoticed?
Partly because a portfolio story is harder to tell than a product story. Integration products are sold and supported by specialists - ACE people know ACE, API Connect people know API Connect, and Confluent has its own community. What only becomes visible when you put them side by side tends to be nobody’s day job.
And partly because attention follows recent work: case studies, press releases, and reference calls are produced around new deployments, while a platform that has been running quietly for fifteen years generates none of them, however much of the business depends on it.
Digia and Savangard cover the entire integration lifecycle, not just each product separately. This includes assessing what an estate actually contains. Designing the target. Standing up the platform. Running the migration. Sorting out the license position, usually a separate negotiation from the technical work, and often the one that decides the business case. Then operating and governing the result, including taking over the day-to-day support.
That last part matters more than it sounds: a migration gets planned rather differently when the same people will be answering the phone about it at three in the morning.
Case example 1: A Central European bank
Close to 500 API services, internal and external, brought behind one governed gateway on IBM webMethods API Management - wired into core banking and into the bank’s identity framework, with user and group management built to its authentication standards, and Elastic Stack underneath for monitoring and analytics.
The hard part was the constraint described above: nobody outside the bank could touch production, and the legacy systems being integrated could not be disrupted, so every deployment and every diagnostic had to be designed around both.
It now runs over 50 million API requests a day at a 99.7 percent success rate.
Case example 2: A consumer-goods manufacturer in 120+ markets
wbMethods on static servers, where an upgrade took months and patching was welded to deployment. Containerized onto Azure Kubernetes Service (AKS) across three Azure regions, ArgoCD for the applications, Prometheus and OpenTelemetry replacing local logs. No freeze window, because the business kept changing throughout.
The containerised webMethods build was new enough then that parts of it needed vendor fixes mid-project. Over 5,000 integrations moved without an outage. Applications start ten times faster, and an upgrade takes weeks instead of months.
Next step, if you have IBM technology in your estate
Neither of the cases above began with a decision to rip anything out. Both began with an inventory.
Therefore, the next step is not a migration decision. It is an inventory: what you run, what it costs, which parts genuinely constrain you, and which are simply old and quietly working. Those last two get confused constantly, which is how organizations spend eighteen months replacing something that was fine.
If any of this matches what you are running, get in touch. Tell us what you have and what is worrying you, and we will tell you what we would look at first. What comes out of our assessment is usually undramatic: a controlled upgrade, a license renegotiation, a governance model, and occasionally "leave it alone for two years."